Just recently got a new computer, has a Pentium G3440 CPU and was initially doing the regular 183k GFLOPs tasks is quite exactly 2h effective CPU time, with benchmarks showing some 3300-3400 floating point and some 8600-8700 integer. Now, after about a week, the time started increasing (though lately I'm getting usually longer ones, just 2-3 of the 183k ones in this batch of 100, but the estimate for them is around 2:07 now, and those 190-196k ones are going to some 2:30-2:40). Benchmarks around 3350 / 8500, but I turned on the benchmark debug flag and I see this:

5/9/2015 10:56:16 AM | | [benchmark] CPU 0: fp 3291457628.207532 int 8553922672.918948 intloops 149584000.000000 inttime 9.952864
5/9/2015 10:56:16 AM | | [benchmark] CPU 1: fp 3400724558.976434 int 0.000000 intloops 0.000000 inttime 0.000000

Since I never turned that flag on before, is that normal, no int ops on 2nd core, or is there a problem? And why the drop anyway?

---

I would say that it is possible your CPU is running too hot and backing of a bit to cool down.

---

Don't think there's any problem with your benchmark:

09/05/2015 10:11:26 |  | [benchmark] Starting floating-point benchmark
09/05/2015 10:11:36 |  | [benchmark] Ended floating-point benchmark
09/05/2015 10:11:41 |  | [benchmark] Starting integer benchmark
09/05/2015 10:11:51 |  | [benchmark] Ended integer benchmark
09/05/2015 10:11:54 |  | [benchmark] Ended benchmark
09/05/2015 10:11:55 |  | [benchmark] CPU 0 has finished
09/05/2015 10:11:55 |  | [benchmark] CPU 1 has finished
09/05/2015 10:11:55 |  | [benchmark] CPU 2 has finished
09/05/2015 10:11:55 |  | [benchmark] CPU 3 has finished
09/05/2015 10:11:55 |  | [benchmark] 4 out of 4 CPUs done
09/05/2015 10:11:55 |  | [benchmark] CPU 0: fp 3105570154.610810 int 9105408180.420843 intloops 150992000.000000 inttime 9.438060
09/05/2015 10:11:55 |  | [benchmark] CPU 1: fp 3075241060.718381 int 0.000000 intloops 0.000000 inttime 0.000000
09/05/2015 10:11:55 |  | [benchmark] CPU 2: fp 3077312298.339559 int 0.000000 intloops 0.000000 inttime 0.000000
09/05/2015 10:11:55 |  | [benchmark] CPU 3: fp 3169438734.897026 int 0.000000 intloops 0.000000 inttime 0.000000
09/05/2015 10:11:55 |  | Benchmark results:
09/05/2015 10:11:55 |  | Number of CPUs: 4
09/05/2015 10:11:55 |  | 3107 floating point MIPS (Whetstone) per CPU
09/05/2015 10:11:55 |  | 9105 integer MIPS (Dhrystone) per CPU
09/05/2015 10:11:57 |  | Resuming computation

Claggy

Author: David Anderson <davea@ssl.berkeley.edu>
Date: 03/06/2007 21:13:38
Message:
- client: fix inconsistent integer benchmarks on Windows

with multicore machines. I don't know why this happened,
but I fixed it by doing integer benchmarks only on CPU zero.
This is OK since cores have separate integer units
(but not necessarily FP units)

client/
cs_benchmark.C

svn path=/trunk/boinc/; revision=12808

This may relate to the problems with precision timing counters under Windows, that Jason was mentioning in another thread.

Edit - might well be related to message 1675126 and https://support.microsoft.com/en-us/kb/895980:

Multi core or multiprocessor systems may encounter Time Stamp Counter (TSC) drift when the time between different cores is not synchronized.

It's running very cool actually. CPU reported temps 48-51C, motherboard 34-37C. Old computer tended to try to hold 67C core temp at a normal room temperature, and the only times I saw it under 60 were the first 30 or so seconds after boot or when the window was open for a while in the middle of winter.

This last reply though, can't say I understand what it means... However, after noticing a steady significant difference between core 0 and 1 (~3300 vs. ~3400 fp steady), and core 1 typically running up to 3C cooler too, I set boinc.exe affinity on core 1 and reran benchmarks and got the expected results again steady (actually ~3400 / ~8600). Seems as if Windows swapped core references or something so as of yesterday, since it benchmarks int on a single core, BOINC ended up doing it on the slightly slower one?
But that still doesn't explain the clear and sudden difference in WU time. Up till yesterday morning I got those WUs like I was saying in almost exactly 2h effective time, and the estimate was around 2:01. By last night, estimate for them was 2:05. Now it's 2:07, and I had 184k WUs done in around 2:10 and 196k ones in over 2:40 already.

---

Estimated times are just that, estimates. With a new computer the program doesn't know what your average time is.

It takes a week or two for the program to figure out what the average is.

Look are the run times in your profile and see what they are actually running.

---

That's what I was looking at, and estimates for those were pretty darn accurate, like I was saying. Ah well, will keep tracking.

---

That's what I was looking at, and estimates for those were pretty darn accurate, like I was saying. Ah well, will keep tracking.

heh, I think with respect to boinc estimates, the quote "Even a stopped clock gives the right time twice a day" fits

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

...no int ops on 2nd core, or is there a problem?...

Yes, that's normal. Because there were problems running the Dhrystone test on multiple cores with some XEON chips, only the first core is tested.

                                                                   Joe