Version 11 (modified by davea, 6 years ago) (diff)



In BOINC, a validator is a program that decides whether results are correct. You must supply a validator for each application in your project, and include it in the <daemons> section of your project configuration file.

Depending on various factors, you may be able to use a standard validator that comes with BOINC, or you may have to develop a custom validator.

  • If your application generates exactly matching results (either because it does no floating-point arithmetic, or because you use homogeneous redundancy) then you can use the 'sample bitwise validator' (see below).
  • If you are using BOINC for 'desktop grid' computing (i.e. you trust all the participating hosts) then you can use the 'sample trivial validator' (see below).
  • Otherwise, you'll need to develop a custom validator for your application.

Two standard validators are supplied:

  • The sample_bitwise_validator requires a strict majority, and regards results as equivalent only if they agree byte for byte.
  • The sample_trivial_validator accepts all results as valid.

By default, a validator grants credit for valid results using the mechanism described here. You can change or disable this using command-line arguments.

Command-line arguments

A validator (either standard or custom) has the following command-line arguments:

--app appname
Name of the application
[ --one_pass_N_WU N ]
Validate at most N WUs, then exit
[ --one_pass ]
Make one pass through WU table, then exit
[ --mod n i ]
Process only WUs with (id mod n) == i. This option lets you run multiple instances of the validator for increased performance.
[ --max_granted_credit X ]
Grant no more than this amount of credit to a result.
[ --update_credited_job ]
For each valid result, create an entry in the credited_job database table. This lets you keep track of which user contributed to each WU, even if you use db_purge.
[ --no_credit ]
Don't grant credit (use this if you grant credit via trickle messages).
[ --credit_from_runtime ]
Grant credit proportional to (runtime * CPU FLOPS). Use this if:
  • the app has only single-threaded CPU versions, and
  • the app's jobs do different amounts of computation on different hosts, e.g. if they exit after a fixed amount of time.