Can anyone explain this?

Matt Giwer
Matt Giwer
Joined: 12 Dec 05
Posts: 144
Credit: 6,891,649
RAC: 0
Topic 195634

There appears to be a problem with the BOINC calibration of the processor.

I have two machines. In both cases the integer and float are per core. I get them from the standard out file. I got the RAC from allprojects.com.

Phenom 1.8 GHz, 8221 int, 1357 float, 1666 RAC
Athlon 2.6 GHz, 3759 int, 612 float, 2367 RAC

The ratio of the clocks is 1.44. The ratio of the RAC is 1.42. The ratio of both integer and float is more than double in favor of the slower machine.

So the speed at which a WU is processed depends upon the clock speed rather than the rate at which numbers are crunched? The BOINC calibration means something other than the usual or something that loves and L3 cache? I admit to being surprised with the results on the slower Phenom machine compared to the Athlon.

These are plain vanilla machines from HP. Both have the same MOBO graphics chipset and neither has a "gamer's" video card. Both run essentially the same linux kernel differing only be Redhat 12 on the slower and 13 on the faster.

Any suggestions?

Metod, S56RKO
Metod, S56RKO
Joined: 11 Feb 05
Posts: 135
Credit: 813,644,064
RAC: 59,311

Can anyone explain this?

There are a couple of factors that affect the reported CPU speed quite a lot.

  • System load at the moment of testing. If system performs some other non-niced tasks when BOINC does benchmarks, indicated CPU speed can be quite lower than the one reported when computer is otherwise idle.

Exact breed of BOINC core client. If you're running not-exactly-same executable on both machines, then calibration loops of both BOINC executables could be quite differently optimized. A while ago there was a movement to optimize the very same calibration loops in order to get client report more OPs to be done in real science application.

Amount of CPU cache: calibration loops run nicely if they fit entirely into CPU cache ... thus slower CPU with larger cache can produce better results. That's not normally the case with science application.

All in all this number is nowadays not used much and should be omitted.

Metod ...

Matt Giwer
Matt Giwer
Joined: 12 Dec 05
Posts: 144
Credit: 6,891,649
RAC: 0

RE: There are a couple of

Quote:
There are a couple of factors that affect the reported CPU speed quite a lot.
  • System load at the moment of testing. If system performs some other non-niced tasks when BOINC does benchmarks, indicated CPU speed can be quite lower than the one reported when computer is otherwise idle.

I chose to give a relevant summary in my post. I have checked several calibrations and they agree to less than 1%.

Quote:
Exact breed of BOINC core client. If you're running not-exactly-same executable on both machines, then calibration loops of both BOINC executables could be quite differently optimized. A while ago there was a movement to optimize the very same calibration loops in order to get client report more OPs to be done in real science application.
Quote:

They both run the same kernel Linux. I do not know what could be other than the same once the linux version is used.

Quote:
Amount of CPU cache: calibration loops run nicely if they fit entirely into CPU cache ... thus slower CPU with larger cache can produce better results. That's not normally the case with science application.

All in all this number is nowadays not used much and should be omitted.

Agreed with all of the above and I do not see it explaining the issue. I tried the slower machine report per core being the error and found a 1.8 vice 1.4 ratio. That is close but then I am sure I can find other numbers to manipulate and get numbers closer to 1.4.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.