BOINC: A System for Public-Resource Computing and Storage David P. Anderson University of California, Berkeley

Paper overview  Defines public-resource computing  Introduces the BOINC platform  Lists public-resource computing projects using the BOINC platform  Discusses BOINC implementation

Public-resource computing  AKA global computing or P2P computing  Combines the resources of personal computers and game consoles belonging to the general public to perform scientific computations  Started with  Great Internet Mersenne Prime Search (GIMPS) (1996)  Distributed.net (1997)

Contrast with grid computing  Grid computing involves "organizationally- owned resources"  Centrally managed by IT professionals  Powered on most of the time  Connected by high-speed links  Malicious behavior handled by organization  None of that is true for public-resource computing.

Specific requirements of public-computing systems  Redundant computing  Against result falsification/fabrication  Cheat-resistant accounting  Support for user-configurable application graphics

BOINC  Berkeley Open Infrastructure for Network Computing  Developed at UCB Space Science Laboratory by the group  started in 1999 and still runs today

Goals of BOINC (I)  Reduce the barriers of entry to public- resource computing:  A project can be run from a single computer running standard open-source software  Share resources among autonomous projects:  Each PC owner can join multiple projects  Results in better resource utilization

Goals of BOINC (II)  Support diverse applications:  Offer various data distribution mechanisms  Support various programming languages  …  Reward participants:  Mostly by giving them credits  System must be cheating-resistant  Also by offering nice graphics  Great screensavers!

Projects using BOINC (I)  search for intelligent extra-terrestrial life  protein behavior  protein folding, misfolding, aggregation and related diseases  Climateprediction.net: long term-climate prediction

Projects using BOINC (II)  long term-climate prediction  CERN projects: were to use in-house PCs  gravitational waves  UCB/Intel study of Internet resources

BOINC overview (I)  Projects:  Have a single master URL  Can involve one or more applications  They may change over time  Server complex of a BOINC project  Centered around a relational database containing most project data  Scheduling server daemons handles RPC from by clients  Data server daemons manage uploads

BOINC overview (II)  BOINC offers tools for  Creating, starting, stopping and querying projects  Adding new applications, new platforms, …  Creating workunits  Monitoring server performance  Conceived to be used by scientists, not IT professionals

BOINC overview (III)  Participants join by registering with web site of project and downloading the BOINC client  Client can run as  Screensaver (with fancy graphics)  Window service (running in the background)  Application (displaying results in tabular form)

Describing computations and data  Applications:  Can have different versions for different participant platforms  Consist of one or more files  Workunits:  Represent inputs to a computation  Include parameters specifying computational step requirements  Results (obvious)

More details  Files associated with  Application versions  Workunits  Results are immutable  Files have numerous BOINC-specific attributes

Client/scheduler interactions  When a client interacts with a scheduling server, it  Reports completed work  Gets a collection of workunits

Redundant computing (I)  BOING supports redundant computing  Projects can specify each workunit should be executed N times  If M  N executions agree on a particular result, it becomes canonical

Redundant computing (II)  Issues:  Must prevent cheaters to create quorums of fabricated results  Each user can provide at most one result for each workunit  Must distinguish between erroneous results and mere numerical variations  Homogeneous redundancy: Same workunit only sent to clients with identical platforms

Failure and backoff  Must prevent server overload after a failure  Everyone wants to reconnect  All client/server communication uses exponential backoff after a failure  Preents avalanches of requests

Participant preferences  User general preferences let users specify numerous parameters  Including transfer limits (for participants having monthly transfer limits) and CPU duty cycles (for participants having overclocked CPUs)

Credit and accounting  To reward participants

User community features  To motivate participant emulation

Platform diversity issues  Maintains multiple versions of application executables  Participants may also request to recompile applications before running them  Anonymous platform mechanism  Useful for  Non standard platforms  Paranoiac participants

Graphics and screensavers  Client software appears monolithic to BOINC participants but comprises four components:  Core client: does the work  Client GUI: provides a user-interface showing computation progress and letting participants quit and join projects  API: report CPU usage and fraction done, handle requests to provide graphics, …  Screensaver

Local scheduling  Decides which projects to run  Goals include  Maximizing resource usage  Meeting result deadlines;  Respecting resource share allocation among projects of each participant  Ensuring some ”variety” among projects  Participants want to see progress in all the projects they have joined

Conclusions  It works  More work still needs to be done

If you want to hear more  David Anderson speaks about and BOINC x6A x6A