Version 5 (modified by 16 years ago) (diff) | ,
---|
Work distribution
A host asks a project for work by including a
<work_req_seconds>X</work_req_seconds>
element in a scheduler RPC request message. This asks the scheduler to return enough work to keep all the host's processors busy for X seconds, given the host's typical usage (i.e. the fraction of time it's turned off or BOINC is suspended, and the other processes that it executes).
BOINC's work distribution policy addresses the (sometimes conflicting) goals of keeping hosts as busy as possible, while minimizing the impact of
- Hosts that repeatedly return results with error outcomes, due to a host-specific problem.
- Malicious participants who attempt to obtain multiple results of the same workunit, in an attempt to obtain unearned credit or have erroneous results accepted as correct.
Work distribution is constrained by a number of rules:
- A result is sent only if an application version is available for the host's platform. If the application's min_version field is nonzero, the version number must at least this value.
- A result is sent only if its disk and memory requirements are met by the host.
- A result is not sent if the estimated latency (based on the host's CPU speed and usage parameters) exceeds the workunit's latency bound.
- A result is not sent if the project has specified a one result per user per workunit flag, and a result of the same workunit has already been sent to a host belonging to the same user.
- A result is not sent if the project has specified a daily result quota per host, and the host has already been sent that many results.
- A project can specify a limit on the number of results sent per RPC.
- A result is not sent if homogeneous redundancy is enabled and another result of the same workunit has been sent to a different type of host.
In general, the BOINC scheduler responds to a work request by enumerating unsent results from the database, filtering them by the above criteria, sending them to the host, and continuing until requested duration X is reached.
For projects that have very large input files, each of which is used by many workunits, BOINC offers an alternative work distribution policy called locality scheduling.