Handling completed jobs

In BOINC lingo, a 'workunit' is a job. A job can have multiple copies, or 'instances'. A 'result' is an instance of a job.

When a job instance is dispatched to a BOINC client (i.e. a volunteer computer), there are various possible outcomes:

• The client processes the job correctly and uploads the output files.
• The client computes the result incorrectly (e.g. due to a hardware error).
• The application crashes.
• The application exceeds resource limits (memory, disk, CPU time) and is aborted by the client.
• The client fails to download or upload files.
• A deadline passes and the result 'times out'. This can happen because because the computer is turned off a lot, or stops running BOINC completely.

BOINC has mechanisms that deal with these situations:

• If an instance errors out or times out, BOINC automatically creates new instances (up to a limit).
• Erroneous results can be detected in various ways, for example by 'replication' (running instances on different hosts and seeing if they agree; see below). For a given job, a 'canonical instance' is selected as the correct output. A job may be flagged as an error, in which case there is no canonical result.

Once a canonical instance has been selected, its output files are processed, possibly with application-specific logic. This is called assimilation.

Job parameters

Jobs have parameters related to the above mechanisms:

• min_quorum: When replication is used, the minimum number of agreeing results; normally 2.
• target_nresults: This many instances are created initially; normally at least min_quorum.
• max_error_results: If this many instances fail (e.g. crash) the workunit is flagged as an error.
• max_total_results If this many instances have been completed without finding a canonical instance, the workunit is flagged as an error.
• max_success_results If this many instances have been successfully completed without finding a canonical instance, the workunit is flagged as an error.

These parameters are specified as part of job submission. They can be specified in the app's XML 'input template'.

Validation

• Job replication
  • Homogeneous redundancy
  • Homogeneous App Version
  • Adaptive replication
• Validators
  • Standard validators
  • Validators in scripting languages
  • Validators in C
  • Credit options

Assimilation

• Assimilation introduction
  • Standard assimilators
  • Assimilators in scripting languages
  • Assimilators in C

Utility functions

• Utility functions for job-processing programs in C++