Changes between Version 1 and Version 2 of RpcPolicy
- Timestamp:
- Apr 25, 2007, 2:19:15 PM (18 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
RpcPolicy
v1 v2 5 5 The scheduler RPC policy has the following goals: 6 6 7 8 7 * Make as few scheduler RPCs as possible. 9 8 * Use random exponential backoff if a project's scheduling servers are down (i.e. delay by a random number times 2^N, where N is the number of unsuccessful attempts). This avoids an RPC storm when the servers come back up. … … 11 10 * Report results before or soon after their deadlines. 12 11 12 == Resource debt == 13 13 14 === Resource debt === 15 The client maintains an exponentially-averaged sum of the CPU time it has devoted to each project. The constant EXP_DECAY_RATE determines the decay rate (currently a factor of e every week). 14 The client maintains an exponentially-averaged sum of the CPU time it has devoted to each project. The constant EXP_DECAY_RATE determines the decay rate (currently a factor of e every week). 16 15 17 16 Each project is assigned a '''resource debt''', computed as 18 17 {{{ 19 18 resource_debt = resource_share / exp_avg_cpu 20 19 }}} 21 20 where 'exp_avg_cpu' is the CPU time used recently by the project (exponentially averaged). Resource debt is a measure of how much work the client owes the project, and in general the project with the greatest resource debt is the one from which work should be requested. 22 21 22 == Minimum RPC time == 23 The client maintains a '''minimum RPC time''' for each project. This is the earliest time at which a scheduling RPC should be done to that project (if zero, an RPC can be done immediately). The minimum RPC time can be set for various reasons: 23 24 24 === Minimum RPC time === 25 The client maintains a '''minimum RPC time''' for each project. This is the earliest time at which a scheduling RPC should be done to that project (if zero, an RPC can be done immediately). The minimum RPC time can be set for various reasons: 26 27 28 * Because of a request from the project, i.e. a <request_delay> element in a scheduler reply message. 25 * Because of a request from the project, i.e. a `<request_delay>` element in a scheduler reply message. 29 26 * Because RPCs to all of the project's scheduler have failed. An exponential backoff policy is used. 30 27 * Because one of the project's computations has failed (the application crashed, or a file upload or download failed). An exponential backoff policy is used to prevent a cycle of rapid failures. 31 28 32 33 === Scheduler RPC sessions === 34 Communication with schedulers is organized into '''sessions''', each of which may involve many RPCs. There are two types of sessions: 35 29 == Scheduler RPC sessions == 30 Communication with schedulers is organized into '''sessions''', each of which may involve many RPCs. There are two types of sessions: 36 31 37 32 * '''Get-work''' sessions, whose goal is to get a certain amount of work. Results may be reported as a side-effect. 38 33 * '''Report-result''' sessions, whose goal is to report results. Work may be fetched as a side-effect. 39 34 40 35 The internal logic of scheduler sessions is encapsulated in the class SCHEDULER_OP. This is implemented as a state machine, but its logic expressed as a process might look like: 41 36 {{{ 42 37 get_work_session() { … … 74 69 } 75 70 }}} 76 71 The logic for initiating scheduler sessions is embodied in the [ClientLogic scheduler_rpcs->poll()] function. 77 72 {{{ 78 73 if a scheduler RPC session is not active
