Credit system goals ¶
Some goals in designing a credit system:
* Device neutrality: similar jobs should get similar credit regardless of what processor or GPU they run on.
* Project neutrality: different projects should grant about the same amount of credit per host, averaged over all hosts.
* Gaming-resistance: there should be a bound on the impact of faulty or malicious hosts.
The first credit system ¶
In the first iteration of BOINC's credit system, "claimed credit" C of job J on host H was defined as
C = H.whetstone * J.cpu_time
There were then various schemes for taking the average or min claimed credit of the replicas of a job, and using that as the "granted credit".
We call this system "Peak-FLOPS-based" because it's based on the CPU's peak performance.
The problem with this system is that, for a given app version, efficiency can vary widely between hosts. In the above example, the 10 GFLOPS host would claim 10X as much credit, and its owner would be upset when it was granted only a tenth of that.
Furthermore, the credits granted to a given host for a series of identical jobs could vary widely, depending on the host it was paired with by replication. This seemed arbitrary and unfair to users.
The second credit system ¶
We then switched to the philosophy that credit should be proportional to the FLOPs actually performed by the application. We added API calls to let applications report this. We call this approach "Actual-FLOPs-based".
SETI@home's application allowed counting of FLOPs, and they adopted this system, adding a scaling factor so that average credit per job was the same as the first credit system.
Not all projects could count FLOPs, however. So SETI@home published their average credit per CPU second, and other projects continued to use benchmark-based credit, but multiplied it by a scaling factor to match SETI@home's average.
This system has several problems:
* It doesn't address GPUs properly; projects using GPUs have to write custom code.
* Project that can't count FLOPs still have device neutrality problems.
* It doesn't prevent credit cheating when single replication is used.
Goals of the new (third) credit system ¶
* Completely automated - projects don't have to change code, settings, etc.
* Device neutrality
* Limited project neutrality: different projects should grant about the same amount of credit per host-hour, averaged over hosts. Projects with GPU apps should grant credit in proportion to the efficiency of the apps. (This means that projects with efficient GPU apps will grant more credit than projects with inefficient apps. That's OK).