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 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. The credit is specified in the <credit> tag of the input template (see JobSubmission). 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.