Some of the posts I've seen fairly recently indicate that some of the 6.12.* versions of BOINC never initialize a certain variable often used in the time limit calculations, and therefore tend to give time limits as if a random number was used in place of this variable.
Therefore, it may be a good idea to modify the program that assigns credits to these workunits, and perhaps also the application program, to gather more information about the various variables used in the credit calculations before that calculation, whether they change unexpectedly during that calculation, and so on, and write a new program to look for unexpected variations in any of those values. Also, how practical is it to set the quorum higher than 1 for at least a few of those low-volume test workunits, in order to gather more information on wide variations returned in the outputs of the workunits? For the time being, it might be a good idea to set a maximum value for credit awarded for a workunit of that low-volume test application, but then leave the calculations otherwise unchanged except for gathering more information on the variables used. > From: "Kamran Karimi" <[email protected]> > Subject: Re: [boinc_dev] [boinc_alpha] CreditNew: Is it really just a > randomnumber generator? > One things that AQUA apps do is to set the fpops_cumulative (to a value > that determines how much work was done) and intops_cumulative (set to > -1, to indicate to the server that fpops_cumulative must be used to > calculate credit). I wonder if this is causing any problems, though as > Richard mentioned, tasks with similar fpops_cumulative values are > getting very different results. > -Kamran > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of David Anderson > Sent: July-11-11 11:15 AM > To: Eric J Korpela > Cc: BOINC Developers Mailing List > Subject: Re: [boinc_dev] [boinc_alpha] CreditNew: Is it really just a > randomnumber generator? > (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_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.
