Hello,

I am trying to do small research of hosts, donating to Rosetta. I noticed large difference between my tested hosts and all other hosts with same CPU by BoincStats "Average credit per CPU second" statistic. Now I am looking for reasons of this.

I noticed, that credits depending on operating system, but this difference is only about 5-10%. But I noticed 50-200% difference from BoincStats averages.

As I know, Rosetta granting credits by all identical CPU(?) average, so average credit must be simmilar to claimed credits. Unfortunately, here is large difference too :)

Maybe someone have minds, what can cause this. I still not tried, but maybe credits depending on WU length based on Rosetta preferences?

Hello,

I am trying to do small research of hosts, donating to Rosetta. I noticed large difference between my tested hosts and all other hosts with same CPU by BoincStats "Average credit per CPU second" statistic. Now I am looking for reasons of this.

I noticed, that credits depending on operating system, but this difference is only about 5-10%. But I noticed 50-200% difference from BoincStats averages.

As I know, Rosetta granting credits by all identical CPU(?) average, so average credit must be simmilar to claimed credits. Unfortunately, here is large difference too :)

Maybe someone have minds, what can cause this. I still not tried, but maybe credits depending on WU length based on Rosetta preferences?

My thoughts/guesses .... and I would be interested in your findings.

OS:
I would expect the same exact hardware to score higher with Windows than Linux because Windows seems to more aggressively use Turbo mode than Linux.

BOINC Manager configuration:
I THINK work done since the last checkpoint is lost when the job is suspended unless you have the option "LEAVE IN MEMORY WHEN SUSPENDED" set. If you don't have that option set, you would probably tend to lose some compute but be charged with the time as tasks are suspended. In other words, you have to do the work twice. This would be more dramatic on smaller systems with less memory.

HW:
Some of the newer machines may be overclocked and distort numbers. My "Intel(R) Core(TM) i7-5930K CPU @ 3.50GHz" is actually running at 4.1GHz. My Gigabyte board comes with a nice application "Easy Tune" that allows me to change the multiplier dynamically from 1.2GHz (energy saving) to 4.3GHz (Extreme). The machine shows up as the default 3.50GHz.

The newer CPU will throttle down the frequency IF it starts getting hot. It will automatically insert halt states to allow the CPU to cool down. You can watch this dynamically in real time using the Linux tool "i7z".

OS:
I would expect the same exact hardware to score higher with Windows than Linux because Windows seems to more aggressively use Turbo mode than Linux.

My experience is that you're right, but I'm not sure that Turbo (e.g. Intel turbo) is responsible for all of it as I've swapped PCs from Windows to Linux on pre-Nehalem CPUs and still seen a bit of a credit drop. It could be due to me using slower disk storage (e.g. compactflash/USB instead of spinny disks or SSDs).

BOINC Manager configuration:
I THINK work done since the last checkpoint is lost when the job is suspended unless you have the option "LEAVE IN MEMORY WHEN SUSPENDED" set. If you don't have that option set, you would probably tend to lose some compute but be charged with the time as tasks are suspended. In other words, you have to do the work twice. This would be more dramatic on smaller systems with less memory.

This is my understanding too.

The Rosetta credit system is a very good measure of a computer's real-world processing contribution. It's (I believe) relatively difficult to cheat it, although I know there are examples of it being wrong (like a recent Atom CPU getting 5k RAC!). (Again, my understanding - may be wrong:) It works by taking a rolling average of the requested credit-per-second (which is BOINC benchmark x CPU time) for each submitted result (each decoy - there may be many decoys in each task your computer uploads) for a given work-unit. The granted credit is then based on the averaged credit-per-decoy from all previous hosts x number of decoys calculated.

Because it works on a levellised credit-per-decoy, and decoys can only be produced the hard way (by calculating them), and the speed that decoys are calculated takes into account things that the BOINC benchmark doesn't, like RAM speed, cache contention, disk speed etc, the result is a pretty stable and fair granted credit system, IMO.

---

I would expect the same exact hardware to score higher with Windows than Linux because Windows seems to more aggressively use Turbo mode than Linux.

I want to share with you experimental results of HP Compaq dc7800, Intel Core2 Duo CPU E6750 @ 2.66GHz [Family 6 Model 15 Stepping 11] and 2GB RAM. I tried it with 32bit Ubuntu 14.04 and 32bit Windows 10.

CPU | Cores | OS | Measured floating point speed | Measured integer speed | Claimed per hour | Granted per hour | Granted/claimed ratio
Intel Core2 Duo CPU E6750 @ 2.66GHz | 2 | Ubuntu | 2989,68 | 7676,18 | 44,47 | 50,73 | 1,14
Intel Core2 Duo CPU E6750 @ 2.66GHz | 2 | Windows 10 | 2560,13 | 5341,02 | 32,92 | 45,79 | 1,39

Also, I tried to run CPU benchmarks on BOINC several times, but results of floating point speed differs only 1-2%.

Hello,

I am trying to do small research of hosts, donating to Rosetta. I noticed large difference between my tested hosts and all other hosts with same CPU by BoincStats "Average credit per CPU second" statistic. Now I am looking for reasons of this.

I noticed, that credits depending on operating system, but this difference is only about 5-10%. But I noticed 50-200% difference from BoincStats averages.

As I know, Rosetta granting credits by all identical CPU(?) average, so average credit must be simmilar to claimed credits. Unfortunately, here is large difference too :)

Maybe someone have minds, what can cause this. I still not tried, but maybe credits depending on WU length based on Rosetta preferences?

My thoughts/guesses .... and I would be interested in your findings.

OS:
I would expect the same exact hardware to score higher with Windows than Linux because Windows seems to more aggressively use Turbo mode than Linux.

But, wouldn't a 100%-all-the-time-on load basically push both OS to use Turbo Mode the same way?

I've read that, at least in WCG applications, Linux tends to score higher.

The newer CPU will throttle down the frequency IF it starts getting hot. It will automatically insert halt states to allow the CPU to cool down. You can watch this dynamically in real time using the Linux tool "i7z".

VERY nice find. I loaded this tool up on my Linux laptop. Apparently with HT on, my Linux machine has been halting every 3-4 seconds due to high temperature. My CPU-Temp monitor updates every 2 seconds (thru Conky) and apparently only gives an average (it didn't show these very short high-temperature spikes).
So, I reduced the number of WUs crunched at a time to 2. Temp is no longer going up and down like before, and every once in a while the multiplier goes to the max setting.

With that said... certain % of the CPUs now go into C3 and even C6 states.
But... Rosetta does use L1-L2 cache like mad... so reducing the number of WUs crunched at a time should in theory allow for faster computations of the remaining 2 WUs that were left crunching... plus the fact that the cores go up to 3GHz instead of 2.78 Ghz?

Ugh, maybe I just need to repaste the CPU, AGAIN, and let it crunch full on.

---

So, I reduced the number of WUs crunched at a time to 2. Temp is no longer going up and down like before, and every once in a while the multiplier goes to the max setting.

Ugh, maybe I just need to repaste the CPU, AGAIN, and let it crunch full on.

Yes, I have problems with my laptops due overheating too, but I am using Tthrottle, which reducing boinc usage and keeping fixed temperature, which I am able to set.

Anyway, for experiments I used desktop computers with good cooling systems, so I am sure, that they runing 100% all time.

The newer CPU will throttle down the frequency IF it starts getting hot. It will automatically insert halt states to allow the CPU to cool down. You can watch this dynamically in real time using the Linux tool "i7z".

VERY nice find. I loaded this tool up on my Linux laptop. Apparently with HT on, my Linux machine has been halting every 3-4 seconds due to high temperature. My CPU-Temp monitor updates every 2 seconds (thru Conky) and apparently only gives an average (it didn't show these very short high-temperature spikes).
So, I reduced the number of WUs crunched at a time to 2. Temp is no longer going up and down like before, and every once in a while the multiplier goes to the max setting.

I've been experimenting with overclocking my AMD8120 from an initial point of complete ignorance and even though I turned off all throttling, it wasn't until I started using HWInfo64 that I saw that even though I was managing to increase my multiplier to a high level without crashing (19x) the CPUs' multiplier was dropping so often to 7x I was getting lower average processing with the higher multiplers.

By reducing the multiplier one notch at a time - to 18.5x then 18x - heat production reduced, multiplier drop-down reduced and average processing actually increased. Weird but true.

I've been messing around with this for 18 months now and I still don't quite feel I've completely got a handle on it yet tbh.

Sorry for the digression.

---

The newer CPU will throttle down the frequency IF it starts getting hot. It will automatically insert halt states to allow the CPU to cool down. You can watch this dynamically in real time using the Linux tool "i7z".

VERY nice find. I loaded this tool up on my Linux laptop. Apparently with HT on, my Linux machine has been halting every 3-4 seconds due to high temperature. My CPU-Temp monitor updates every 2 seconds (thru Conky) and apparently only gives an average (it didn't show these very short high-temperature spikes).
So, I reduced the number of WUs crunched at a time to 2. Temp is no longer going up and down like before, and every once in a while the multiplier goes to the max setting.

I've been experimenting with overclocking my AMD8120 from an initial point of complete ignorance and even though I turned off all throttling, it wasn't until I started using HWInfo64 that I saw that even though I was managing to increase my multiplier to a high level without crashing (19x) the CPUs' multiplier was dropping so often to 7x I was getting lower average processing with the higher multiplers.

By reducing the multiplier one notch at a time - to 18.5x then 18x - heat production reduced, multiplier drop-down reduced and average processing actually increased. Weird but true.

I've been messing around with this for 18 months now and I still don't quite feel I've completely got a handle on it yet tbh.

Sorry for the digression.

Good cooling might be key. Also, because heat goes up linearly with clock speed, but with the square of the voltage, if you can reduce the voltage slightly it can make a big difference to power consumption and therefore heat produced.

---

The newer CPU will throttle down the frequency IF it starts getting hot. It will automatically insert halt states to allow the CPU to cool down. You can watch this dynamically in real time using the Linux tool "i7z".

VERY nice find. I loaded this tool up on my Linux laptop. Apparently with HT on, my Linux machine has been halting every 3-4 seconds due to high temperature. My CPU-Temp monitor updates every 2 seconds (thru Conky) and apparently only gives an average (it didn't show these very short high-temperature spikes).
So, I reduced the number of WUs crunched at a time to 2. Temp is no longer going up and down like before, and every once in a while the multiplier goes to the max setting.

I've been experimenting with overclocking my AMD8120 from an initial point of complete ignorance and even though I turned off all throttling, it wasn't until I started using HWInfo64 that I saw that even though I was managing to increase my multiplier to a high level without crashing (19x) the CPUs' multiplier was dropping so often to 7x I was getting lower average processing with the higher multiplers.

By reducing the multiplier one notch at a time - to 18.5x then 18x - heat production reduced, multiplier drop-down reduced and average processing actually increased. Weird but true.

I've been messing around with this for 18 months now and I still don't quite feel I've completely got a handle on it yet tbh.

Sorry for the digression.

Good cooling might be key. Also, because heat goes up linearly with clock speed, but with the square of the voltage, if you can reduce the voltage slightly it can make a big difference to power consumption and therefore heat produced.

This is even with water-cooling! Turbo is permanently on and while temperatures are significantly down and well within limits it continues to occur. I've now reduced the multiplier to 17.5 and reduced voltage by 2 clicks, so that my average processor speed has increased slightly again.

Because the PC is stable (running 247 for days at a time) I think I can reduce voltage by 1 more click and hopefully run permanently stable turbo, increasing my average processor speed again.

This may all sound very unlikely, but my granted credit was always way less than my claimed credit before, while now it's much closer and probably the granted credit is a touch higher now.

I wouldn't have realised any of this without HWInfo which seems to be much more reflective of what's happening under the hood than the utility I was using before (or maybe I just understand it better).

---

The newer CPU will throttle down the frequency IF it starts getting hot. It will automatically insert halt states to allow the CPU to cool down. You can watch this dynamically in real time using the Linux tool "i7z".

VERY nice find. I loaded this tool up on my Linux laptop. Apparently with HT on, my Linux machine has been halting every 3-4 seconds due to high temperature. My CPU-Temp monitor updates every 2 seconds (thru Conky) and apparently only gives an average (it didn't show these very short high-temperature spikes).
So, I reduced the number of WUs crunched at a time to 2. Temp is no longer going up and down like before, and every once in a while the multiplier goes to the max setting.

I've been experimenting with overclocking my AMD8120 from an initial point of complete ignorance and even though I turned off all throttling, it wasn't until I started using HWInfo64 I saw that even though I was managing to increase my multiplier to a high level without crashing (19x) the CPUs' multiplier was dropping so often to 7x I was getting lower average processing with the higher multiplers.

By reducing the multiplier one notch at a time - to 18.5x then 18x - heat production reduced, multiplier drop-down reduced and average processing actually increased. Weird but true.

I've been messing around with this for 18 months now and I still don't quite feel I've completely got a handle on it yet tbh.

Sorry for the digression.

Good cooling might be key. Also, because heat goes up linearly with clock speed, but with the square of the voltage, if you can reduce the voltage slightly it can make a big difference to power consumption and therefore heat produced.

This is even with water-cooling! Turbo is permanently on and while temperatures are significantly down and well within limits it continues to occur. I've now reduced the multiplier to 17.5 and reduced voltage by 2 clicks, so that my average processor speed has increased slightly again.

Because the PC is stable (running 247 for days at a time) I think I can reduce voltage by 1 more click and hopefully run permanently stable turbo, increasing my average processor speed again.

This may all sound very unlikely, but my granted credit was always way less than my claimed credit before, while now it's much closer and probably the granted credit is a touch higher now.

I wouldn't have realised any of this without HWInfo which seems to be much more reflective of what's happening under the hood than the utility I was using before (or maybe I just understand it better).

Did this overnight and it's worked - permanently (first 15 hours anyway) stable turbo mode @ 17.5x multiplier with no dropdowns gaining me the last 15MHz of average processor speed (4214.6MHz overclocked from 3100MHz default), which is a higher average than 19.0x multiplier (nominal 4575MHz but average 3900MHz) ever provided me. I do this with a 240.8MHz FSB (up from a default 200) and I'm sure the lower voltages put less strain on the rest of my machine.

I've finally got to the point where I'm going to stop fiddling with the blooming thing - I thought it would never end.

---

The newer CPU will throttle down the frequency IF it starts getting hot. It will automatically insert halt states to allow the CPU to cool down. You can watch this dynamically in real time using the Linux tool "i7z".

VERY nice find. I loaded this tool up on my Linux laptop. Apparently with HT on, my Linux machine has been halting every 3-4 seconds due to high temperature. My CPU-Temp monitor updates every 2 seconds (thru Conky) and apparently only gives an average (it didn't show these very short high-temperature spikes).
So, I reduced the number of WUs crunched at a time to 2. Temp is no longer going up and down like before, and every once in a while the multiplier goes to the max setting.

I've been experimenting with overclocking my AMD8120 from an initial point of complete ignorance and even though I turned off all throttling, it wasn't until I started using HWInfo64 I saw that even though I was managing to increase my multiplier to a high level without crashing (19x) the CPUs' multiplier was dropping so often to 7x I was getting lower average processing with the higher multiplers.

By reducing the multiplier one notch at a time - to 18.5x then 18x - heat production reduced, multiplier drop-down reduced and average processing actually increased. Weird but true.

I've been messing around with this for 18 months now and I still don't quite feel I've completely got a handle on it yet tbh.

Sorry for the digression.

Good cooling might be key. Also, because heat goes up linearly with clock speed, but with the square of the voltage, if you can reduce the voltage slightly it can make a big difference to power consumption and therefore heat produced.

This is even with water-cooling! Turbo is permanently on and while temperatures are significantly down and well within limits it continues to occur. I've now reduced the multiplier to 17.5 and reduced voltage by 2 clicks, so that my average processor speed has increased slightly again.

Because the PC is stable (running 247 for days at a time) I think I can reduce voltage by 1 more click and hopefully run permanently stable turbo, increasing my average processor speed again.

This may all sound very unlikely, but my granted credit was always way less than my claimed credit before, while now it's much closer and probably the granted credit is a touch higher now.

I wouldn't have realised any of this without HWInfo which seems to be much more reflective of what's happening under the hood than the utility I was using before (or maybe I just understand it better).

Did this overnight and it's worked - permanently (first 15 hours anyway) stable turbo mode @ 17.5x multiplier with no dropdowns gaining me the last 15MHz of average processor speed (4214.6MHz overclocked from 3100MHz default), which is a higher average than 19.0x multiplier (nominal 4575MHz but average 3900MHz) ever provided me. I do this with a 240.8MHz FSB (up from a default 200) and I'm sure the lower voltages put less strain on the rest of my machine.

I've finally got to the point where I'm going to stop fiddling with the blooming thing - I thought it would never end.

I spoke marginally too soon. I only got 10 of those 15MHz over 3 days. One further click of voltage reduction (0.00625v for a total of 0.02500v) has now done the trick and perfectly stable over 3 days too.

Definitely definitely stopped fiddling now (probably...)

...plus, I gained a new team member. Yay!

---