Changes between Version 26 and Version 27 of CreditNew

Timestamp:

Mar 25, 2010, 2:48:20 PM (14 years ago)

Author:

davea

Comment:

--

CreditNew

@@ -1 +1 @@
 = New credit system design =
 
-== Peak FLOPS and efficiency ==
-
-BOINC estimates the peak FLOPS of each processor.
+== Definitions ==
+
+BOINC estimates the '''peak FLOPS''' of each processor.
 For CPUs, this is the Whetstone benchmark score.
 For GPUs, it's given by a manufacturer-supplied formula.
@@ -12 +12 @@
 So a given job might take the same amount of CPU time
 and a 1 GFLOPS host as on a 10 GFLOPS host.
-The "efficiency" of an application running on a given host
+The '''efficiency''' of an application running on a given host
 is the ratio of actual FLOPS to peak FLOPS.
 
@@ -22 +22 @@
 
  * For our purposes, the peak FLOPS of a device
-   is single or double precision, whichever is higher.
-   Differentiating between single and double would unnecessarily
-   complicate things, and the distinction will disappear soon anyway.
+   uses single or double precision, whichever is higher.
 
 == Credit system goals ==
@@ -34 +32 @@
 
  * Project neutrality: different projects should grant
-   about the same amount of credit per host,
-   averaged over all hosts.
-
- * Cheat-proof
-
-It's easy to show that both goals can't be satisfied simultaneously.
+   about the same amount of credit per host, averaged over all hosts.
 
 == The first credit system ==
@@ -93 +86 @@
 == Goals of the new (third) credit system ==
 
- * Completely automated - projects don't have to
-   change code, settings, etc.
+ * Completely automated - projects don't have to change code, settings, etc.
 
  * Device neutrality
@@ -126 +118 @@
    (e.g., a CPU job that does lots of disk I/O)
    PFC() won't reflect this.  That's OK.
-   The key thing is that BOINC reserved the device for the job,
+   The key thing is that BOINC allocated the device to the job,
    whether or not the job used it efficiently.
  * peak_flops(J) may not be accurate; e.g., a GPU job may take
@@ -153 +145 @@
 ''A posteriori'' estimates of job size may exist also
 (e.g., an iteration count reported by the app)
-but using this for anything introduces a new cheating risk,
-so it's probably better not to.
+but this introduces a new cheating risk.
 
 == Cross-version normalization ==
 
-If a given application has multiple versions (e.g., CPU and GPU versions)
-the credit per job is adjusted
+A given application may have multiple versions (e.g., CPU and GPU versions).
+If jobs are distributed uniformly to versions,
+all versions should get the same average credit.
+We adjust the credit per job
 so that the average is the same for each version.
 
@@ -167 +160 @@
 An app version V's jobs are then scaled by the factor
 
- S(V) = (X/PFC^mean^(V))
-
-The "Version-Normalized Peak FLOP Count", or VNPFC(J) is
-
- VNPFC(J) = S(V) * PFC(J)
+ Scale(V) = (X/PFC^mean^(V))
 
 Notes:
@@ -182 +171 @@
    It's not exactly "Actual FLOPs", since the most efficient
    version may not be 100% efficient.
+ * If jobs are not distributed uniformly among versions
+   (e.g. if SETI@home VLAR jobs are done only by the CPU version)
+   then this mechanism doesn't work as intended.
+   One solution is to create separate apps for separate types of jobs.
 
 == Cross-project normalization ==
@@ -203 +196 @@
 V's jobs are then scaled by S(V) as above.
 
+Projects will export the following data:
+{{{
+for each app version
+   app name
+   platform name
+   recent average granted credit
+   plan class
+   scale factor
+}}}
+
+The BOINC server will collect these from several projects
+and will export the following:
+{{{
+for each plan class
+   average scale factor (weighted by RAC)
+}}}
+We'll provide a script that identifies app versions
+for GPUs with no corresponding CPU app version,
+and sets their scaling factor based on the above.
+
 Notes:
 
@@ -215 +228 @@
 we maintain PFC^mean^(H, A),
 the average of PFC(J)/E(J) for jobs completed by H using A.
-The '''claimed FLOPS''' for a given job J is then
-
- F = VNPFC(J) * (PFC^mean^(V)/PFC^mean^(H, A))
-
-and the claimed credit (in Cobblestones) is
-
- C = F*100/86400e9
+
+This yields the host scaling factor
+
+ Scale(H) = (PFC^mean^(V)/PFC^mean^(H, A))
 
 There are some cases where hosts are not sent jobs uniformly:
@@ -238 +248 @@
    than average.
 
+== Claimed credit ==
+
+The '''claimed FLOPS''' for a given job J is then
+
+ F = PFC(J) * S(V) * S(H)
+
+and the claimed credit (in Cobblestones) is
+
+ C = F*100/86400e9
+
 == Computing averages ==
 
@@ -250 +270 @@
 The code that does this is
 [http://boinc.berkeley.edu/trac/browser/trunk/boinc/lib/average.h here].
-
-== Cross-project scaling factors ==
-
-Projects will export the following data:
-{{{
-for each app version
-   app name
-   platform name
-   recent average granted credit
-   plan class
-   scale factor
-}}}
-
-The BOINC server will collect these from several projects
-and will export the following:
-{{{
-for each plan class
-   average scale factor (weighted by RAC)
-}}}
-We'll provide a script that identifies app versions
-for GPUs with no corresponding CPU app version,
-and sets their scaling factor based on the above.
 
 == Anonymous platform ==