Changes between Initial Version and Version 1 of CreditAlt

Timestamp:

Sep 14, 2011, 2:16:23 PM (13 years ago)

Author:

davea

Comment:

--

CreditAlt

@@ +1 @@
+[[PageOutline]]
+= Alternative mechanisms for granting credit =
+
+By default, BOINC automatically grants credit for valid jobs.
+It does this in a way that is
+ * Device-neutral: a given job gets the same credit no matter
+   which host or device (CPU/GPU) it runs on.
+ * Project-neutral: a given host gets roughly the same credit per day
+   no matter what project it's attached to.
+
+Projects should use the default credit system
+unless there is a clear reason not to.
+To handle such cases, BOINC provides the following alternative mechanisms:
+
+== Credit via trickle messages ==
+
+If you have very long-running jobs (a week or more) you may want to
+grant credit incrementally.
+To do so:
+
+ * Have your application periodically send [TrickleApi trickle-up messages]
+  with variety '''runtime''' and content
+{{{
+<runtime>X</runtime>
+}}}
+  where X is the runtime since the last trickle message.
+
+ * Run the '''trickle_credit''' daemon as follows:
+{{{
+trickle_credit --variety runtime --max_runtime Y
+}}}
+where Y is the limit on runtime
+(typically the period of the trickle messages).
+
+ * Run your validator for the app with the '''--no_credit''' option
+
+The '''trickle_credit''' daemon grants credit in proportion to (runtime * CPU FLOPS),
+hence this approach should be used only for applications with only single-CPU versions.
+
+This approach is not device-neutral because hosts with the same peak FLOPS
+may have different actual FLOPS for the app version.
+
+== Credit for nonuniform jobs ==
+
+The default credit system assumes that a given job always does
+roughly the same amount of computation, no matter what host it runs on.
+This is not the case, for example,
+if your application is designed to run for a certain amount of time and then exit.
+
+For such applications, run your validator with the
+{{{
+--credit_from_runtime X
+}}}
+option.
+This grants credit in proportion to (runtime * CPU FLOPS),
+hence this approach should be used only for applications with only single-CPU versions.
+
+X is the maximum runtime for which credit will be granted.
+This provides a measure of cheat-proofing.
+
+== Explicit credit ==
+
+You can assign credit to WUs when they are created.
+If X is the number of FLOPs that the WU is expected to use,
+the credit should be X*200/(86400*1e9).
+Then run your validator with the
+{{{
+--credit_from_wu
+}}}
+option.