(I'm moving this to boinc_dev; not appropriate for boinc_alpha) Re Eric's idea: we do maintain std dev. However, this wouldn't work if there is an initial sequence of consistent, small values, and large values thereafter.
Richard, rest assured that CreditNew is not a RNG. Something anomalous is happening at AQUA, and Kamran and I are going to track it down shortly. -- David On 11-Jul-2011 7:05 AM, Eric J Korpela wrote: > One problem, I think, that might lead to this is the use of moving averages. > (I haven't verified this numerically) They are vulnerable to high value > outliers. If there were also a measure approximating standard deviation it > might be possible to exclude numbers that are more that two standard > deviations off the mean, which would lead to more stable moving averages. > Maybe. > > Eric > > On Fri, Jul 8, 2011 at 4:43 PM, Richard Haselgrove > <[email protected]> wrote: >> Sorry for the provocative title, but that's the word on the street (project >> message boards, for those who don't read them). >> >> Here's some evidence to back up the theory, from AQUA today. >> >> AQUA has been a project which awards deterministic credit, controlled by a >> bespoke usage of<fpops_cumulative> in the<result> record. The project >> also uses close-to-current BOINC server code (currently at svn 23790), with >> minimal modification. >> >> Some recent server code change, as yet unidentified, has broken the >> deterministic credit awards. I can only surmise that the change relates to >> the promotion of CreditNew to be the default credit schema. >> >> There have been wild fluctuations (several hundred million credits per WU) >> in credit granted for a recent low-volume test application. We can dismiss >> those as outliers (although the evidence will remain on the face of the >> stats sites for months or years). But my observation relates to the >> long-established, production status Fokker-Planck application. >> >> My host >> http://aqua.dwavesys.com/results.php?hostid=17302&offset=0&show_names=0&state=0&appid=3 >> was allocated two consecutive tasks in a single scheduler contact at >> 1:43:20 UTC today, and returned both results in a single scheduler contact >> at 16:08:46 UTC. >> >> The two result records returned to the server show a minor difference in >> CPU and elapsed timings, but are otherwise effectively identical. In >> particular, both results have the same<fpops_cumulative>, and AQUA would >> like to stipulate that they receive identical credit. >> >> <result> <name>fp_5jul11_bm_16_005_500_000-1_998_0</name> >> <final_cpu_time>72198.170000</final_cpu_time> >> <final_elapsed_time>18889.015625</final_elapsed_time> >> <exit_status>0</exit_status> <state>5</state> >> <platform>windows_intelx86</platform> <version_num>210</version_num> >> <plan_class>fpmt</plan_class> >> <fpops_cumulative>7407970000000.000000</fpops_cumulative> >> <intops_cumulative>-1.000000</intops_cumulative> >> <app_version_num>210</app_version_num> ... </result> <result> >> <name>fp_5jul11_bm_16_005_500_000-1_997_0</name> >> <final_cpu_time>70629.910000</final_cpu_time> >> <final_elapsed_time>18252.515625</final_elapsed_time> >> <exit_status>0</exit_status> <state>5</state> >> <platform>windows_intelx86</platform> <version_num>210</version_num> >> <plan_class>fpmt</plan_class> >> <fpops_cumulative>7407970000000.000000</fpops_cumulative> >> <intops_cumulative>-1.000000</intops_cumulative> >> <app_version_num>210</app_version_num> ... </result> >> >> Yet the credit award is very different: >> >> 12053709 10755813 8 Jul 2011 | 1:43:20 UTC 8 Jul 2011 | 16:08:46 UTC >> Completed and validated 18,889.02 72,198.17 1,762.44 D-Wave's Fokker-Planck >> Simulation : Multi-Threaded Anonymous platform (CPU) 12053708 10755812 8 >> Jul 2011 | 1:43:20 UTC 8 Jul 2011 | 16:08:46 UTC Completed and validated >> 18,252.52 70,629.91 14,198.05 D-Wave's Fokker-Planck Simulation : >> Multi-Threaded Anonymous platform (CPU) >> >> That's 1,762.44 credits for one member of the matched pair, 14,198.05 >> credits for the other. >> >> AQUA is a quorum=1 project, so there's no effect from validation partners >> ('wingmen'). Since both time of issue and time of report are identical, >> there should be no scope for variation in either project averages or host >> averages between the two events. >> >> Where, then, does the eight-fold variation in credit come from? And what >> impression does it give in relation to the mathematical accuracy of the >> BOINC platform? _______________________________________________ boinc_alpha >> mailing list [email protected] >> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_alpha To unsubscribe, >> visit the above URL and (near bottom of page) enter your email address. >> > _______________________________________________ boinc_alpha mailing list > [email protected] > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_alpha To unsubscribe, > visit the above URL and (near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
