Version 14 (modified by 13 years ago) (diff) | ,
---|
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.
Options related to credit. Don't use these options in general. With no options, validators will grant credit in a fair way.
- [ --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.
- [ --credit_from_wu ]
- Grant credits written in WU template. See CreditAlt and JobSubmission.