Posts by Beyond

Message boards : Number crunching : low credit on some WUs

Message boards : Number crunching : HELP - Consistant 0% Progress - Client Problem?

Message boards : Number crunching : Cobblestones

Message boards : Number crunching : Cobblestones

What is our next step? We will put a survey open for the next 20 days to collect your votes and set up the credit system accordantly.

Message boards : Number crunching : Cobblestones

[i]Generally there are a lot of problems with the BOINC benchmarks even if one does not manipulate them. The benchmark values vary a lot when comparing different BOINC versions and/or a different OS. As an example look at this computer running Client 5.10.45 under Linux and this completely identical machine just with WinXP. The Linux hosts registers benchmark values of only[quote]Measured floating point speed 747.84 million ops/sec
Measured integer speed 1382.91 million ops/sec

while under Windows I see

Measured floating point speed 1335.22 million ops/sec
Measured integer speed 2249.84 million ops/sec

Quite a difference I think.

Furthermore there are sometimes severe problems with CPUs capable of dynamically changing their clockspeed. That are virtually all Notebook CPUs. But you may know that AMD CPUs downclock itself under light load to 800MHz or 1GHz, while under full load they may run at more than 3GHz. I've seen several systems where the benchmark caused too less load to "wake up" the CPU to the full clockspeed, whereas the WUs run at full throttle afterwards. This leads to severly underclaiming hosts and if the benchmark values get (correctly) recalculated at some point (there is a random componont to this problem) they would get their WUs marked as invalid (because of claiming much more than before) with your proposed system. Another problem is that there may be heavy (non-BOINC) activity on the system when the Benchmark is executed. This will also lead to severly reduced scores.

But also overclaiming benchmarks are entirely possible without willfully manipulating something. Just think of the new Core i7 series and its "Turbo" feature. If only one core is loaded and/or the CPU temperature is low it raises the frequency of the loaded core(s). This leads easily to benchmark scores (which partly runs only single threaded!) not representative of the actual crunching speed. The hyperthreading feature makes this even worse actually. I think I gave already that example of 88 credits claimed by a Phenom or Core2 and 124 credits claimed by a Core i7 for the same WU. And this problem will continue to get more pronounced as the CPU manufactures will implement further features helping the crunching speed but not the benchmark score or increase the functionality of such automated load and temperature dependend clocking schemes for CPUs like Cool&Quiet, SpeedStep or that Turbo feature.

All in all, even if the benchmark could not be manipulated, it still lacks the property to represent the crunching power of a system. So why on earth do you want to base the credits on it?
With the provisions you have taken you try the repair a concept that is literally fubar. Maybe you should ask yourself why most projects (especially the bigger ones) use fixed credits. The simple answer is that it is probably the easiest and safest way.

Message boards : Number crunching : Cobblestones

Message boards : Number crunching : Work Units That Never Want To End

>>> Is there an admin reading this thread?

Bear in mind the time differences, what is it where the team members are, how long have they had at work?

Message boards : Number crunching : Work Units That Never Want To End