Changes between Version 4 and Version 5 of CreditOptions

Timestamp:

May 15, 2018, 2:15:01 PM (7 years ago)

Author:

davea

Comment:

--

CreditOptions

@@ -65 +65 @@
 the job credit is C times the number of iterations performed.
 
-To use this: in your validator, have the init_result() function return the credit for the job.
+To use this:
+ * In your validator, have the init_result() function set result.claimed_credit.
+ * Run the validator with '''--post_assigned_credit'''.
+
+A job's granted credit is the claimed credit of its canonical instance.
 
 == Runtime-based credit ==
 
 Use this if the app has only CPU app versions.
-The "claimed credit" for a job instance is runtime*ncpus*benchmark.
+The "claimed credit" for a job instance is runtime*ncpus*peak_flops,
+where peak_flops is the host's Whetstone benchmark.
+The job's granted credit is the average of the instance claimed credits.
 
-To use this: pass the --credit_from_runtime option to the app's validator.
-
-The app's efficiency (the ratio between peak FLOPS and actual FLOPS)
-can vary somewhat between hosts (e.g. because of different memory speeds,
-or because small RAM causes paging).
-Therefore there will be variation between claimed credit for identical jobs,
-but generally this will be a factor of 2 or so.
+To use this: pass the '''--credit_from_runtime''' option to the app's validator.
+You must also supply '''--max_granted_credit'''.
 
 Runtime-based credit can't be used if the app has GPU versions
 because efficiency can vary by orders of magnitude between CPU and GPU versions.
 
-Runtime-based credit is not cheat-proof.
+Runtime-based credit is limited by max_granted_credit, but is otherwise not cheat-proof.
 
 == Adaptive credit ==