| | 1 | = Research projects involving BOINC = |
| | 2 | |
| | 3 | Possible research projects involving BOINC and volunteer computing, |
| | 4 | appropriate for senior-level class projects or Masters theses. |
| | 5 | |
| | 6 | == Virtualizing volunteer computing == |
| | 7 | |
| | 8 | The volunteer computing host population is highly heterogeneous |
| | 9 | in terms of software environment (operating system type and version, |
| | 10 | system libraries, installed packages). |
| | 11 | Projects are faced with the difficult task of building application |
| | 12 | versions for all these different environments; |
| | 13 | this is a significant barrier to the usage of volunteer computing. |
| | 14 | |
| | 15 | This problem can be mitigated using virtual machine technology. |
| | 16 | In this approach, a hypervisor such as VMWare or VirtualBox is |
| | 17 | installed (manually or automatically) on volunteer hosts. |
| | 18 | An application consists of a virtual machine image |
| | 19 | containing the application proper together with the required libraries and packages. |
| | 20 | A "wrapper" program provides an interface between |
| | 21 | the BOINC client and the hypervisor, so that, for example, |
| | 22 | the application can be suspended and resumed in accordance |
| | 23 | with user preferences. |
| | 24 | |
| | 25 | The project (a collaboration with CERN and INRIA) |
| | 26 | is to implement this "volunteer cloud" model, |
| | 27 | to optimize it (e.g., to minimize VM image sizes), |
| | 28 | and to develop tools to facilitate its use by computational scientists. |
| | 29 | |
| | 30 | == Analyze and improve adaptive replication == |
| | 31 | |
| | 32 | Because volunteer hosts may be error-prone or malicious, |
| | 33 | volunteer computing requires result validation. |
| | 34 | The general way to do this is by replication: |
| | 35 | run each job on 2 computers and make sure the results agree. |
| | 36 | |
| | 37 | To reduce the 50% overhead of two-fold replication, |
| | 38 | BOINC has a mechanism called "adaptive replication" |
| | 39 | that runs jobs with no replication on hosts with low error rates, |
| | 40 | while continuing to randomly intersperse replicated jobs. |
| | 41 | |
| | 42 | The project is to identify possible counter-strategies for adaptive replication, |
| | 43 | to establish bounds on the overall effectiveness of adaptive replication, |
| | 44 | and to identify refinements that increase the effectiveness. |
| | 45 | |
| | 46 | == Extend and refine the BOINC credit system == |
| | 47 | |
| | 48 | The idea of "credit" - a numerical measure of work done - |
| | 49 | is essential to volunteer computing, |
| | 50 | as it provides volunteers an incentive and a basis for competition. |
| | 51 | Currently, BOINC's credit mechanism is based on the |
| | 52 | number of floating-point operations performed. |
| | 53 | |
| | 54 | The project is to design a new credit system where |
| | 55 | a) credit can be given for resources other than computing |
| | 56 | (e.g., storage, network bandwidth); |
| | 57 | b) the credit given per FLOP can depend on factors such |
| | 58 | as RAM size and job turnaround time. |
| | 59 | Ideally the system allow a game-theoretic proof |
| | 60 | that it leads to an optimal allocation of resources. |
| | 61 | |
| | 62 | == Latency-oriented volunteer computing == |
| | 63 | |
| | 64 | The early volunteer computing projects (SETI@home, Climateprediction.net) |
| | 65 | are "throughput oriented": they want to maximize the number of jobs |
| | 66 | completed per day, not minimize the turnaround time of individual jobs. |
| | 67 | BOINC's scheduling mechanisms reflect this; for example, they try to |
| | 68 | assign multiple jobs at a time so that client/server interactions are minimized. |
| | 69 | |
| | 70 | More recent volunteer computing projects are "latency-oriented": |
| | 71 | they want to minimize the makespan of batches of jobs. |
| | 72 | The project is to redesign BOINC's scheduling mechanisms so that they |
| | 73 | can support latency-oriented computation, |
| | 74 | and to validate the new mechanisms via simulation |
| | 75 | (using an existing simulator). |
| | 76 | |
| | 77 | == Volunteer data archival == |
| | 78 | |
| | 79 | While BOINC is currently used for computation, |
| | 80 | it also provides primitives for distributed data storage: |
| | 81 | file transfers, queries, and deletion. |
| | 82 | The project is to develop a system that uses these primitives |
| | 83 | to implement a distributed data archival system |
| | 84 | that uses replication to achieve target levels of |
| | 85 | reliability and availability. |
| | 86 | |
| | 87 | == Invisible GPU computing == |
| | 88 | |
| | 89 | BOINC has recently added support for GPU computing, |
| | 90 | and several projects now offer applications for NVIDIA and ATI GPUs. |
| | 91 | One problem with this is that GPU usage is not prioritized, |
| | 92 | so when a science application is running |
| | 93 | the performance of user-visible applications is noticeable degraded. |
| | 94 | As a result, BOINC's default behavior is that science applications |
| | 95 | are not run while the computer is in use (i.e., while there has been |
| | 96 | recent mouse or keyboard activity). |
| | 97 | |
| | 98 | The project (in collaboration with NVIDIA and possibly AMD/ATI) |
| | 99 | is to make changes to BOINC and to the GPU drivers |
| | 100 | so that the GPU can be used as much as possible, |
| | 101 | even while the computer is in use, |
| | 102 | without impacting the performance of user-visible applications. |
| | 103 | |
| | 104 | == Estimating job completion times in a heterogeneous environment == |
| | 105 | |
| | 106 | Accurate job completion time estimates are essential to BOINC. |
| | 107 | Underestimates can waste computation, |
| | 108 | and overestimates can cause resource idleness. |
| | 109 | BOINC's current mechanisms for estimating job completion times |
| | 110 | have various shortcomings: |
| | 111 | a) they require projects to estimate job FLOPS requirements in advance, |
| | 112 | and to estimate the FLOPS performance of applications on particular hosts; |
| | 113 | most projects don't have the ability or willingness to provide |
| | 114 | accurate estimates; |
| | 115 | b) they are based on peak hardware performance |
| | 116 | (e.g., benchmark values), and actual application performance |
| | 117 | can be wildly different, especially for multi-threaded and GPU applications. |
| | 118 | |
| | 119 | The project is to design, implement, and study a system that automatically |
| | 120 | estimates job completion times on heterogeneous hosts, |
| | 121 | and that provides estimates of the actual number of FLOPS performed |
| | 122 | by a given job. |