The goals of CreditNew involve long-term averages. It makes no promises about individual jobs or about credit/hour.
If a project has highly variable jobs, this translates into highly variable credit for individual jobs. But the long-term average stuff should still hold. If anyone has a specific suggestion for how to make credit less variable on the short term, while still preserving the long-term goals, let me know. BTW: the server maintains the variance of elapsed time and turnaround on a (host, app version) basis. For everything else it maintains only the mean. Variance isn't currently used for anything. -- David On 07-Nov-2011 10:25 AM, Richard Haselgrove wrote: > Part 2 of this research: Credit > > Because the NumberFields tasks are so variable (from 2 ro 300,000 seconds), > I've been looking at the rate that credit has been awarded - Credits per hour > (of runtime) gives a nice human-scale value. > > Here are the results for my four hosts at NumberFields. All four were > attached at the same time (note the consecutive HostIDs): in particular, the > two Q6600 hosts have identical hardware. > > http://img46.imageshack.us/img46/826/numberfieldscreditperho.png > > The problem is that the rate at which credit is granted depends critically on > the host APR value. With a non-deterministic project, especially in the early > days after attachment, APR is heavily influenced by the random processing > time of the early tasks. The credit/hour for all hosts were tightly grouped > for the first 10 tasks, when APR is effectively ignored, but thereafter they > diverge spectacularly. Hosts 1288 and 1289 happened to get short tasks first, > so APR was artificially high when it was first used for credit calculation: > hosts 1290 and 1291 happened to draw longer-running tasks. > > It was host 1290 which received the 300,000 second task > (http://numberfields.asu.edu/NumberFields/result.php?resultid=292439), and > was awarded 4,500 credits (in round figures). At very much the same time, the > identical host 1291 returned > http://numberfields.asu.edu/NumberFields/result.php?resultid=317447, getting > almost the same credit for just 43,000 seconds of work. > > It's discrepancies like that which lead users, and project administrators, to > distrust CreditNew. I think it needs more work, especially if BOINC is going > to continue to support non-deterministic projects. > _______________________________________________ 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. _______________________________________________ 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.
