Validation

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 a default mechanism (described here). There are several alternative ways of granting credit.

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 job.

[ --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.
• Details.