| 23 | |
| 24 | == Improved scheduling policies == |
| 25 | |
| 26 | Dozens of changes to BOINC's client and server scheduling policies have been proposed |
| 27 | (see, for example, the archives of the boinc_alpha email list). |
| 28 | Use the BOINC client emulator and/or EmBOINC to study some of these. |
| 29 | |
| 30 | == Symbiotic job scheduling == |
| 31 | |
| 32 | It has been observed (see UCSD work) that different combinations of applications |
| 33 | run more efficiently than others on multiprocessors, |
| 34 | because of their respective memory access patterns. |
| 35 | Instrument the BOINC client to measure this effect |
| 36 | (i.e., to maintain logs of the rate of progress of applications |
| 37 | running in different combinations). |
| 38 | Estimate the overall throughput increase that could be gained by |
| 39 | doing "symbiosis-aware" job scheduling. |
| 40 | If it's worth doing, implement it. |
95 | | == Extend and refine the BOINC credit system == |
| 112 | == Globalize resource share == |
| 113 | |
| 114 | Currently resource share is enforced on a per-host basis; |
| 115 | each host's processing resources are allocated in a way that matches |
| 116 | resource share as closely as possible. |
| 117 | This can be improved in 2 ways: |
| 118 | |
| 119 | First, enforce resource share on a per-volunteer basis. |
| 120 | Suppose a volunteer is attached to projects A and B, |
| 121 | and has two hosts, H and J. |
| 122 | Suppose A runs efficiently on H (e.g. because H has a GPU supported by A) |
| 123 | and B runs efficiently on B. |
| 124 | Then we can increase overall throughput by |
| 125 | using H entirely for A, and J entirely for B. |
| 126 | |
| 127 | Second, enforce resource share on a global (cross-volunteer) basis. |
| 128 | Suppose volunteer V supports project A but has hosts that |
| 129 | run project B efficiently, and that V trusts B. |
| 130 | Suppose volunteer W is in the symmetric situation. |
| 131 | Then we can increase overall throughput by using |
| 132 | V's hosts for B, and W's hosts for A. |
| 133 | (This idea is due to Arnaud Legrand from INRIA; please contact him). |
| 134 | |
| 135 | In both cases, a study should be one before implementing anything. |
| 136 | |
| 137 | == Generalize the BOINC credit system == |
123 | | BOINC's scheduling mechanisms reflect this; for example, they try to |
124 | | assign multiple jobs at a time so that client/server interactions are minimized. |
125 | | |
126 | | More recent volunteer computing projects are "latency-oriented": |
127 | | they want to minimize the makespan of batches of jobs. |
128 | | The project is to redesign BOINC's scheduling mechanisms so that they |
129 | | can support latency-oriented computation, |
130 | | and to validate the new mechanisms via simulation. |
| 162 | |
| 163 | See PortalFeatures. |
| 164 | |
| 165 | == Intra-project resource allocation == |
| 166 | |
| 167 | Currently BOINC has only crude mechanisms for allocation resources |
| 168 | within a project |
| 169 | (e.g., a project that serves multiple scientists). |
| 170 | Design a quota system. |
| 171 | See PortalFeatures. |