1. BOINC: An Open Platform for Public-Resource Computing David P. Anderson Space Sciences Laboratory U.C. Berkeley

2. Public-resource computing Home PCs business academic Advantages: scale free growth public education no policy issues Challenges: low BW at client costly BW at server firewall/NAT issues sporadic connection untrustworthy, insecure clients server security heterogeneity need PR, glitzy GUI your computers

3. Why share an infrastructure? Research lab X University YPublic project Z projects applications resource pool Participants install one program, select projects, specify constraints; all else is automatic Projects are autonomous Advantages of a shared platform: Better long-term resource utilization Better instantaneous resource utilization Faster/cheaper for projects, software is better Easier for projects to get participants Participants learn more

4. Goals of BOINC (Berkeley Open Infrastructure for Network Computing) Public-resource computing/storage Multi-project, multi-application –Participants can apportion resources Handle fairly diverse applications Work with legacy apps Support many participant platforms Small, simple

5. General structure of BOINC Project: Participant: Scheduling server (C++) BOINC DB (MySQL) Work generation data server (HTTP) App agent data server (HTTP) Web interfaces (PHP) Core agent (C++) Project back end Retry generation Result validation Result processing Garbage collection

6. Data model File attributes: –Name –URL list –Persistent flag –Upload-when-present flag Files may originate in client or in project work manager Projects can use participant disks for long- term data archival

7. Computing model Applications, platforms, app versions Workunits –Inputs to a computation –Estimates of resource requirements Results –Outputs of a computation

8. Hosts and scheduling Host measurements –CPU performance (integer/FP/memory) –RAM, cache, disk free/total –On/connected statistics –Network bandwidth statistics Workunit properties –RAM/disk/computation requirements Scheduling policy –feasibility –High/low water mark

9. Accounting and result validation Standardized unit of credit –CPU time * (int+FP+mem) –Project-specific benchmark? Result validation –Compare redundant results, flag incorrect results Granted credit: –Minimum of claimed credit among correct results

10. Participant preferences Examples: –Work only while user away –Confirm before connecting –Don’t work if on batteries –High, low water marks –Limits on disk space, bandwidth –Application-specific preferences –List of projects + authenticators + % allocation Edited via Web interface

11. Application Programming Checkpoint/restart Filename translation Graphics –OpenGL-based –Application window or screensaver

12. Conclusion BOINC status –Mostly feature-complete –Client runs on Linux, Solaris, Windows, MacOS X –Small: client is 5,000 lines, server 2,000 Projects: –Astropulse (later this year) –Other SETI@home (Parkes etc.) –Folding@home, climate prediction –Others: rendering? Theorem proving?