boinc

Page: Validators

Table of Contents

Command-line arguments

--app appname
[ -d N ]
[ --sleep_interval n ]
[ --one_pass_N_WU N ]
[ --one_pass ]
[ --dry_run ]
[ --mod n i ]
[ --max_wu_id n ]
[ --min_wu_id n ]
[ --max_granted_credit X ]
[ --update_credited_job ]
[ --wu_id N ]
[ --no_credit ]
[ --credit_from_runtime ]
[ --credit_from_wu ]
[ --check_punitive]

A validator is a program that decides whether completed jobs are "valid". You must specify a validator for each application in your project, and include it in the <daemons> section of your project configuration file.

Validating a completed job has 2 parts:

Syntax check: verify that its output files are present on the server and have the correct format.
Replication check: if the job is replicated, compare its replicas. If a strict majority are found to be "equivalent", those replicas are considered valid and the rest are marked as invalid.

Validators grant credit for valid results. By default, this uses the mechanism described here. There are several alternative ways of granting credit.

BOINC comes with several 'standard' validators. For a particular application, you may want to define your own syntax check for output files, or your own notion of "equivalence" (for example, regarding floating-point numbers as equivalent if they agree within some tolerance). In such cases, you can develop application-specific validators in either C++ or scripting languages.

Command-line arguments

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

--app appname

Name of the application

[ -d N ]

Sets the log verbosity level. 1=low ... 4=high.

[ --sleep_interval n ]

Sleep n secs if there was nothing to do within the last pass

[ --one_pass_N_WU N ]

Validate at most N WUs, then exit

[ --one_pass ]

Make one pass through WU table, then exit

[ --dry_run ]

Don't update db, just write logs (for debugging)

[ --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_wu_id n ]

Process only WUs with id <= n

[ --min_wu_id n ]

Process only WUs with id >= n

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

[ --wu_id N ]

Process the WU with the given ID (for debugging).

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.

[ --check_punitive]

This will run the validator for failed tasks (Compute error) so the validator can check for known host issues and set the max number of jobs per day to one to avoid that host getting more tasks.

Home