> The goals of CreditNew involve long-term averages. > It makes no promises about individual jobs or about credit/hour.
I have been following the CreditNew discussion from the beginning. And this is news to me. Seriously. I had no idea that it allows for this kind of behavior, at least not beyond the first several tasks for a particular host. I thought everything would get about the same credits very quickly. Some thoughts: 1) Seemingly randomly awarded credits are going to piss off volunteers. Wait, that sounds hypothetical. Let me rephrase. It has already pissed off volunteers at every project where it has been implemented (check out the message boards). And I am not talking about the "credits are too high/low" old nonsense. I am talking about complaints about how the credits are not consistent. I assume because it grates on the idea of fair play. Maybe explaining (every time) that long-term averages are better than the other guy getting 10x credits right now, will work. I doubt it. But in the end it is up to the poor admins to try to defend the behavior of CreditNew. And it is usually a surprise to the admins as well. 2) So it is expected that credits for individual jobs appear to be awarded randomly, to the volunteers. Fine. This should be documented somewhere, so that the admins understand that this is *expected* behavior, and so they know what they are getting into *before* implementing. I looked on the trac wiki, but didn't see anything that said so explicitly (maybe I missed it?): <http://boinc.berkeley.edu/trac/wiki/CreditNew>. I think it needs to be added...in BOLD. 3) There needs to be some kind of boiler plate made available to the admins, to help them explain this behavior to their volunteers. Because they *will* be challenged on this. Repeatedly. 4) There should be something that shows the volunteers which credit system a project is using, with a link to the wiki. Perhaps on the server status page? It could help to curtail the inevitable "what's going on with the credits?" questions. Erik On Nov 7, 2011, at 11:12 AM, David Anderson wrote: > 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. _______________________________________________ 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.
