zombie67
07-09-11, 10:24 AM
This was posted to the BOINC email list, so FYI for those not on the list. It appears the implementation of the new DA credit methodology (AKA CreditNew) is dorked up. To be clear, Richard is *not* talking about the super huge credits handed out at AQUA over the past several days. That is a different problem. I think there are three projects currently using CreditNew: SETI, AQUA, and T4T (which has other problems with the credits being awarded, but let's not get off on a tangent in this thread).
From: Richard Haselgrove
Date: July 8, 2011 4:43:52 PM PDT
To: boinc_alpha@ssl.berkeley.edu
Subject: [boinc_alpha] CreditNew: Is it really just a random number generator?
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?
From: Richard Haselgrove
Date: July 8, 2011 4:43:52 PM PDT
To: boinc_alpha@ssl.berkeley.edu
Subject: [boinc_alpha] CreditNew: Is it really just a random number generator?
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?