Variation in runtimes for same credit
16 Oct 2007 19:03:16 UTC
Topic 193230
(moderation:
I understand "it's about the science", but let's cut through all that... Credit is a motivator.
As such, I see a significant problem with the huge variation in runtimes for the same frequency range all being granted the same credit amount. Sure, you could argue that the credit is granted on the average runtime and that perhaps the fast results are getting "too much" credit, while the slower results are getting "too little"...and that supposedly that "averages out over time", but I don't quite see how that one could guarantee that a particular host would not be getting the slower running units on a continual basis...
Example on my system:
One (rounded) 222 credit result took 39768 seconds.
Another 222 credit result took 46787 seconds (rounded to nearest second).
Folks, that's a (rounded to one decimal) 17.6% delta in runtime. 221.96 * 1.176 = 261.02
I mention this because with nearly 18% variation (and possibly more, as I'm still running results in the same set), then this probably needs a little attention from the project team...
Respectfully...
Brian
Variation in runtimes for same credit
)
see this answer from Bernd Machenschalk...
[Edit] well, in fact it's not an answer but a comment that they are working on this issue...
Udo
RE: see this answer from
)
As some people have noticed, the variation seems to follow a certain pattern in the sequence of results and is by no means random, so there's hope that an improved mathematical model for the "expected CPU time" can be achieved.
CU
Bikeman
Definetly a quite predictable
)
Definetly a quite predictable variation, i have collected some data on R3 and got the same curves on Linux as those Windows results posted in the S5R3 thread By Haselgrove and Archae.
http://einsteinathome.org/node/193160&nowrap=true#75697
Team Philippines
Yup, that was very useful in
)
Yup, that was very useful in understanding the variation.
OTOH, maybe we should ask all participants to align their CPUs to North and analyse the variation for a Doppler shift. Maybe there's a GW causing a periodic die-shrinkage and therefore faster runtime :-) :-) :-) :-)
CU
Bikeman
Very nice idea :-D
)
Very nice idea :-D