When should the core client ask a project for more work,
which project should it ask,
and how much work should it ask for?
The goals of the CPU scheduler and work-fetch policies are
(in descending priority):
- Results should be completed and reported by their deadline
(results reported after their deadline
may not have any value to the project and may not be granted credit).
- NCPUS processors should be kept busy.
- At any given point, enough work should be kept on hand
so that NCPUS processors will be busy for at least
min_queue days (min_queue is a user preference).
- Project resource shares should be honored over the long term.
- If a computer is attached to multiple projects,
execution should rotate among projects on a frequent basis.
The policies are designed to accommodate all scenarios,
including those with computers that are slow or are attached
to a large number of projects.
In previous versions of BOINC,
the core client attempted to maintain at least one result
for each attached project,
and would do weighted round-robin CPU scheduling among all projects.
In some scenarios (any combination of slow computer,
lots of projects, and tight deadlines) a computer could
miss the deadlines of all its results.
The new policies solve this problem as follows:
-
Work fetch is limited to ensure that deadlines can be met.
A computer attached to 10 projects might
have work for only a few (perhaps only one) at a given time.
-
If deadlines are threatened,
the CPU scheduling policy switches to a mode
(earliest deadline first) that optimizes the likelihood
of meeting deadlines, at the expense of variety.
Concepts and terms
Wall CPU time
A result's wall CPU time is the amount of wall-clock time
its process has been runnable at the OS level.
The actual CPU time may be much less than this,
e.g. if the process does a lot of paging,
or if other (non-BOINC) processing jobs run at the same time.
BOINC uses wall CPU time as the measure of how much resource
has been given to each project.
Why not use actual CPU time instead?
- Wall CPU time is more fair in the case of paging apps.
- The measurement of actual CPU time depends on apps to
report it correctly.
Sometimes apps have bugs that cause them to always report zero.
This screws up the scheduler.
Result states
A result is runnable if
- Neither it nor its project is suspended, and
- its files have been downloaded, and
- it hasn't finished computing
A result is runnable soon if
- Neither it nor its project is suspended, and
- it hasn't finished computing
Project states
A project is runnable if
- It's not suspended, and
- it has at least one runnable result
A project is downloading if
- It's not suspended, and
- it has at least one result whose files are being downloaded
A project is contactable if
- It's not suspended, and
- its master file has already been fetched, and
- it's not deferred (i.e. its minimum RPC time is in the past), and
- it's no-new-work flag is not set
A project is potentially runnable if
- It's either runnable, downloading, or contactable.
Debt
Intuitively, a project's 'debt' is how much work is owed to it,
relative to other projects.
BOINC uses two types of debt;
each is defined related to a set S of projects.
In each case, the debt is recalculated periodically as follows:
- A = the wall CPU time used by projects in S during this period
- R = sum of resource shares of projects in S
- For each project P in S:
- F = P.resource_share / R (i.e., P's fractional resource share)
- W = A*F (i.e., how much wall CPU time P should have gotten)
- P.debt += W - P.wall_cpu_time (i.e. what P should have gotten
minus what it got).
- P.debt is normalized (e.g. so that the mean or minimum is zero).
Short-term debt is used by the CPU scheduler.
It is adjusted over the set of runnable projects.
It is normalized so that minimum short-term debt is zero,
and maximum short-term debt is no greater than 86400 (i.e. one day).
Long-term debt is used by the work-fetch policy.
It is adjusted over the set of potentially runnable projects.
It is normalized so that average long-term debt is zero.
Required time fraction
A result's required time fraction (RTF) is its
estimated remaining CPU time divided by the time to its deadline.
SHOULD WE ALSO TAKE INTO ACCOUNT FACTORS BESIDES CPU TIME?
A result's cumulative required time fraction (CRTF)
of a result R is the estimated remaining CPU time
of R and all results with earlier deadlines,
divided by the time until R's deadline.
Example:
| Result |
Remaining CPU time |
Time until deadline |
RTF |
CRTF |
| A |
5 hours |
50 hours |
0.1 |
0.1 |
| B |
76 hours |
100 hours |
0.76 |
0.81 |
| C |
500 hours |
5000 hours |
0.1 |
0.12 |
The CPU scheduling policy
The CPU scheduler has two modes, normal and
Earliest Deadline First (EDF).
In normal mode, the CPU scheduler runs the project(s)
with the greatest short-term debt.
Specifically:
- Set the 'anticipated debt' of each project to its short-term debt
- Find the project P with the greatest anticipated debt,
select one of P's runnable results
(picking one that is already running, if possible)
and schedule that result.
- Decrement P's anticipated debt by the 'expected payoff'
(the total wall CPU in the last period divided by NCPUS).
- Repeat steps 2 and 3 for additional CPUs
Over the long term, this results in a round-robin policy,
weighted by resource shares.
In EDF mode, the CPU scheduler
schedules the runnable results with the earliest deadlines.
This allows the client to meet deadlines that would otherwise be missed.
The CPU scheduler runs when a result is completed,
when the end of the user-specified scheduling period is reached,
when new results become runnable,
or when the user performs a UI interaction
(e.g. suspending or resuming a project or result).
The work-fetch policy
X is the estimated wall time by which the number of
runnable results will fall below NCPUS.
min_queue is the user's network-connection period general preference.
work_fetch_OK is a flag set by the mode selection algorithm (see below).
The work-fetch policy maintains an 'overall urgency':
-
NEED_IMMEDIATELY:
there is at least one idle CPU
-
NEED:
X < min_queue
-
OK:
X > min_queue, work_fetch_OK is true
-
DONT_NEED:
work_fetch_OK is false
In addition, the work-fetch policy maintains a per-project work-fetch mode:
R(P) = fractional resource share of P
X(P) = estimated wall time when number of runnable results for P
will fall below NCPUS*R(P)
-
NEED_IMMEDIATELY:
no results of P are runnable soon.
-
NEED:
X(P) < min_queue * R(P)
-
OK:
X(P) > min_queue * R(P),
and P is not suspended or deferred or no-new-work
-
DONT_NEED:
P is suspended or deferred or no-new-work
Mode selection
Work_fetch_OK is set to false if either
- The sum of all RTFs is > 0.8
- The CRTF of any result is > 0.8
EDF mode is used if either
- The CRTF of any result is > 0.8
- The deadline of any result is earlier than one day from now
- The deadline of any result is less than
2 * min_queue from now.
";
page_tail();
?>