Changes between Version 6 and Version 7 of CreditOptions

Timestamp:

Jul 18, 2018, 4:56:41 PM (7 years ago)

Author:

davea

Comment:

--

CreditOptions

@@ -86 +86 @@
 Runtime-based credit is limited by max_granted_credit, but is otherwise not cheat-proof.
 
+== Runtime-based 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.
+
 == Adaptive credit ==