What is Claimed vs. Granted credit?

[HankB]

And why is it never discussed.

Most of my systems produce less granted than claimed credit, but for an Atom based system, the granted credit (little as it is ) is usually about double the claimed credit.

 

[Bobnova]

The claimed credit is the amount of useful work your box thinks it did, the granted credit is the amount of useful work the server thinks your box did.
You'll find a few here and there that claim 50 and grant 160+, that's when you know that box found something tasty.

 

[drshivas]

Here's a little more info I came across earlier this year on this not so straightforward subject : http://www.overclockers.com/forums/showthread.php?t=667234&highlight=credit

 

[HankB]

I found some more info on this at: http://boinc.berkeley.edu/trac/wiki/CreditNew

There's some pretty dense reading there! One interesting part is that a host will be penalized if the algorithm thinks it is cheating. I wonder if that logic ever gets triggered in error. Other than that, I'd need to read, re-read and study the article to get a better understanding of how this is done.

 

[Careface]

I wonder if that logic ever gets triggered in error.

It's unlikely. Much like how Tasks/day can drop incredibly quickly when you constantly report invalid WU, sending back clearly fake credit claims would simply alert the scheduler to start monitoring that client; each subsequent excessive credit claim would reduce the tasks/day. Unfortunately this "punishment" makes it incredibly easy to cheat the system, but thankfully result replication adds a layer of protection to this.

My main concern (concern is perhaps the wrong word here; I'm not worried about it per se, I can just see it as being a potential issue) is about wu.fpops_bound. Unless a "reasonable" limit is set, it is possible, even likely, that older CPUs with limited instruction sets running unoptimised clients could in fact trigger this and abort the WU. One of the main issues with claimed credit is the cross-platform differences in how CPUs calculate tasks. Unless everyone was running the same CPU with the same level of app optimisation and the same instruction set, the calculated fpops will always differ. As a side note, this is why the second system failed so badly. It was literally whetstone_benchmark * CPU_time. Not only did this have major variation in actual fpops due to varying levels of optimisation (SSE being vastly faster than MMX, for instance), but also was subject to other credit claim boosting techniques like optimised BOINC.exe clients which caused abnormally high benchmarks results. I remember back when I first started crunching SETI under the BOINC regime, optimised BOINC.exe clients were all the rage - my old AXP2000+ @ 2.2ghz (what a beast! ) could have a measured integer speed of 10,000+ MIPS. For comparison, my i7-960 @ 3.6ghz "only" has a measured integer speed of ~8,500 MIPS. Thus, for a 40min WU (yeah, that's all they took back in the day!) you could claim anywhere upto 200+ credit. Pair that with someone using the same technique, and *bam!* hugely inflated RAC.

Anyway, that was a massive tangent from my original point which is "while it is possible that it gets triggered in error, the devs of BOINC spent a good amount of time devising ways to minimise any instance of it". That's partly why claimed credit, RAC, etc are such overly complicated calculations: They like to stretch their PhDs in maths