1. Emulating Volunteer Computing Scheduling Policies Dr. David P. Anderson University of California, Berkeley May 20, 2011

2. Volunteer computing ● 800K computers ● 85% Win, 7% Mac, 7% Linux ● 2.4 cores/computer ● 41% have a modern GPU ● 65% average availability ● 90% behind firewall or NAT ● 12 PetaFLOPS ● worth $5 billion/year on Amazon EC2

3. BOINC CPU s GPUs

4. BOINC CPU s GPUs BOINC client jobs

5. BOINC CPU s GPUs BOINC client jobs Project schedule r DB scheduler RPC

6. BOINC CPU s GPUs BOINC client jobs Einstein@home 50 % IBM World Community Grid Climateprediction.net 20 % 30 %

7. Client scheduling policies ● Job scheduling policy ● what jobs to run ● whether to leave suspended jobs in memory ● Work fetch policy ● when to get more jobs ● what project to get them from ● how much to request These policies have big impact on system performance. They must work in a large space of scenarios

8. Scenarios ● Preferences ● Hardware ● Availability (computing, network) ● # of projects ● For each project/application ● distribution of job size ● accuracy of runtime estimate ● latency bound ● resource usage ● project availability

9. The BOINC project ● 2.5 developers ● A couple of computers each ● We can’t reproduce most scenarios

10. So... ● How can we design good scheduling policies? ● How can we debug the BOINC client? ● How can we plan for the future? ● many cores ● faster GPUs ● tight latency bounds ● large-RAM applications

11. Early days ● Design plausible policies, test on our computers ● Release software to the public ● Monitor message boards

12. Using volunteer testers ● ~100 volunteers run suite of tests on pre- release software ● Report results via web interface

13. What if there are problems? ● BOINC client can be configured to generate detailed log messages in ~20 areas ● Ask volunteer to send us message log ● Debug by looking at log, code ● Ask volunteer to install new version ● Repeat as needed

14. The BOINC Client Emulator Main logic Scheduling policies Availability Job execution Scheduler RPC Emulated (same source code) Simulated

15. Inputs ● Client state file ● describes hardware, availability, projects and their characteristics ● Preferences, configuration files ● Scheduling policy choices ● current client implements 2 of each ● Duration, time step of simulation

16. Emulator outputs ● Figures of merit ● idle fraction ● wasted fraction ● resource share violation ● monotony ● RPCs per job ● Timeline ● message log ● graphs of scheduling data

17. Emulator interfaces ● Web-based ● volunteers upload scenarios ● can see all scenarios, run simulations against them, comment on them ● Scripted ● sweep an input parameter ● compare 2 policies across a set of scenarios

18. Usage ● By volunteer testers ● see a problem ● upload scenario, reproduce problem in emulator ● developers can study problem under debugger ● By developers ● assemble a library of scenarios ● develop/debug using the emulator

19. Case studies ● Resource share enforcement ● Old: per resource type ● New: across all resource types ● Job fetch policy ● Old: keep buffer full; often fetch a single job ● New: hysteresis

20. Future work ● Characterize the scenario population ● Monte-Carlo sampling ● Study new policies ● e.g. alternatives to EDF ● More features in emulator ● memory usage ● file transfer time ● application checkpointing behavior ● Better model of scheduler behavior ● maybe emulate it also (EmBOINC)