Changes between Version 1 and Version 2 of CreditOptions

Timestamp:

May 3, 2018, 12:42:25 AM (7 years ago)

Author:

davea

Comment:

--

CreditOptions

@@ -12 +12 @@
 Credit is used for two purposes:
 
-1) For users, to see their rate of progress,
-to compete with other users or teams,
-and to compare the performance of hosts.
+ 1. For users, to see their rate of progress,
+  to compete with other users or teams,
+  and to compare the performance of hosts.
 
-2) To get an estimate of the peak performance available to a particular project,
-or of the volunteer host pool as a whole.
+ 2. To get an estimate of the peak performance available to a particular project,
+  or of the volunteer host pool as a whole.
 
 For 2) we care only about averages.
@@ -79 +79 @@
 because efficiency can vary by orders of magnitude between CPU and GPU versions.
 
-Currently this assigns the claimed credit of the canonical result to all results.
-TODO: average over valid results.
+Runtime-based credit is not cheat-proof.
 
 == Adaptive credit ==
@@ -94 +93 @@
 values for workunit fp_ops_est that are correlated with the actual FLOPs.
 Use a constant value if you're not sure.
+
+== Credit averaging ==
+
+If you use replication, runtime-based and adaptive credit can produce
+different "claimed credit" for each job instance.
+The validator code averages these in tricky way I don't quite understand
+(Kevin invented it).
+It does not take the minimum.
+We should probably provide this as an option,
+to make runtime-based credit more cheat-proof.
+However, this won't work if you use adaptive replication,
+where many jobs have only one instance.