Changes between Version 7 and Version 8 of ClientSched

Timestamp:

Nov 21, 2011, 12:29:41 AM (12 years ago)

Author:

davea

Comment:

--

ClientSched

@@ -11 +11 @@
 
 Note: a '''processor type''' is either CPU or a GPU vendor.
-There may be multiple '''instances'' of each processor type.
+There may be multiple '''instances''' of each processor type.
 
 The goals of these policies are (in descending priority):
@@ -45 +45 @@
  * For each processor type, the number of currently idle instances.
 
- * For each processor type, the '''saturated''': the amount of time
+ * For each processor type, the '''saturated time''': the amount of time
    that all instances are busy.
 
- * For each task T, a flag T.deadline_miss indicating whether the task
+ * For each task T, a flag '''T.deadline_miss''' indicating whether the task
    missed its deadline in the simulation.
 
@@ -64 +64 @@
 recently by the project's tasks relative to its resource share.
 
-The '''scheduling priority''' of a project P is computed as
+The scheduling priority of a project P is computed as
 
 {{{
@@ -94 +94 @@
   whenever the saturated period is less than min_buffer.
  * Adjust SP(P) based on the amount of work currently queued
- * Ask the fetchable project with greatest SP(P) for "shortfall" seconds of work.
+ * Ask the fetchable project with greatest SP(P) for work.
+   We request enough jobs to fill the number of idle instances,
+   and to use at least "shortfall" instance-seconds.
  * Whenever a scheduler RPC to project P is done
    (e.g. to report results) and SP(P) is greatest among fetchable projects
    for a given processor type, request "shortfall" seconds of that type.
 
+=== Per-processor-type backoff ===
+
+The client keeps track of whether projects have work for particular processor types,
+so that it doesn't keep asking them for types of work they don't have.
+
+To do this, it maintains a separate backoff timer per (project, resource type).
+The backoff interval is doubled up to a limit (1 day)
+whenever we ask for work of that type and don't get any work;
+it's cleared whenever we get a job of that type.
+Note: if we decide to ask a project for work for resource A,
+we may ask it for resource B as well, even if it's backed off for B.
+
+This mechanism is independent of the overall backoff timer for each project,
+which is triggered by requests from the project, RPC failures, job errors and so on.