-
Notifications
You must be signed in to change notification settings - Fork 512
Custom applications and job processing
Job processing in BOINC involves several parts:
- Applications (the programs that run on volunteers' computers)
- Job submission and control
- Handling completed and timed-out jobs
- Input and output files handling
BOINC provides various alternatives for each of these.
In BOINC terminology, an application (or 'app') is not a single program; it's a set of programs (for different platforms and processor types) that do the same computation. These programs are called app versions.
A project can have multiple applications. You can create applications using the administrative web interface, or using a CLI tool called xadd.
Jobs are submitted to applications, not app versions. BOINC decides what app version to use when sending a job to a host.
A platform is the combination of an operating and processor type. BOINC defines a set of platforms. App versions are associated with platforms.
Some app version have more specific requirements; e.g. they may require a GPU of a particular vendor and model. Each set of requirements is called a plan class. BOINC defines a set of plan classes, and you can define your own. An app version can be associated with a plan class as well as a platform.
- A 'workunit' is a job. It refers to an app, and includes a set of input files.
- A 'result' is an instance of a job, run on a particular computer. It refers to a workunit and (after it has completed) includes a set of output files.
- A 'batch' is a collection of workunits. It can be associated with a user (its submitter). It can be controlled (aborted, retired) as a unit.
Files that exist on clients (application files, input files) are 'immutable': once you've used a name for a file, you can't use the same name for a file with different contents. To enforce this, filenames typically have version numbers or timestamps.
(BUDA hides this from users by automatically generating unique internal names for files.)
BOINC provides several ways to build and package your applications.
Before submitting jobs, you'll need to move input files to the server, and 'stage' them for downloading by clients:
There are several options for submitting jobs:
You need to tell BOINC how to deal with completed jobs, including failures (e.g. if your app exceeds resource limits or crashes on the client), and time outs. You can tell BOINC how to 'validate' jobs - perhaps by replicating them and comparing the results. For successful and valid jobs, you need to tell BOINC what to do with the output files.
Once valid job instances have been found, you'll need to handle their output files in some way, perhaps by transferring them from the server to another computer. There are several options: