2002-04-30 22:22:54 +00:00
|
|
|
<h2>Compute model: work distribution</h2>
|
|
|
|
|
|
|
|
<p>
|
|
|
|
Results are not necessarily dispatched one at a time.
|
|
|
|
Instead, each participant host maintains an estimate
|
|
|
|
of the amount of work remaining
|
|
|
|
(i.e. the time until one of its processors will be idle).
|
|
|
|
Each host also has two scheduling parameters,
|
|
|
|
the <b>high-water mark</b> and the <b>low-water mark</b>
|
|
|
|
(these are part of the host's "preferences", discussed later).
|
|
|
|
|
|
|
|
<p>
|
|
|
|
Normally the work remaining is between the high- and low-water marks.
|
2002-07-15 20:11:48 +00:00
|
|
|
When the work remaining reaches the low-water mark,
|
2002-04-30 22:22:54 +00:00
|
|
|
the core client contacts one or more scheduling servers,
|
2002-07-01 22:41:09 +00:00
|
|
|
and attempts to get enough work to exceed the high-water mark. The
|
2002-07-15 20:11:48 +00:00
|
|
|
scheduling server sends a maximum of four weeks of work. If a work unit is
|
|
|
|
not feasible for a host because it consumes too many system resources,
|
|
|
|
the scheduling server will not send that work unit.
|
2002-04-30 22:22:54 +00:00
|
|
|
|
|
|
|
<p>
|
|
|
|
The amount of work (measured in FP/int ops) sent
|
|
|
|
in a single scheduling RPC can be limited by the project,
|
|
|
|
on a per-application basis.
|
|
|
|
|
|
|
|
<p>
|
|
|
|
This scheme allows hosts that are sporadically connected
|
|
|
|
(because they're portable or have modem-based connections)
|
|
|
|
to avoid becoming idle due to lack of work.
|
|
|
|
|
|
|
|
<p>
|
|
|
|
<b>To do</b>: per-workunit flag saying to return the result ASAP?
|