A Guided Tour of BOINC

David P. Anderson

Space Sciences LabUniversity of California, Berkeley

TACCNovember 8, 2013

BOINC in a nutshell

● BOINC is a batch system for resources that are– Extremely heterogeneous– Numerous– Sporadically available and connected– High-churn– Error-prone– Untrusted and anonymous

BOINC components

Job handling(C++)

Web interfaces(PHP)

BOINC client(C++)BOINC API (C+

+)

application

client server

BOINC abstractions

● Application● Platform

– windows_x86_64– x86_64-linux-gnu– x86_64_apple-darwin– arm-android-linux-gnu

BOINC abstractions

● App version– App, platform, version#– A set of files, including executable– “plan class”; determines processor usage

● # CPUs● # GPUs

BOINC abstractions

● Job– List of input files– Latency bound– Resource usage

● Disk, memory, FLOPS

● Job instance

BOINC abstractions

App

App version

Platform

Job

Job instance

BOINC client: directory structure

Boinc/

projects/

proj1_url/

data1.txt

slots/

0/

in.txt

link

The BOINC data model

● Files are immutable● Client garbage-collects files● Data files can be marked as “sticky”● App version files are automatically sticky

BOINC client: runtime system

Shared memoryMessage-passing

BOINCclient

application

Main thread

API thread

● Process control– Suspend/resume/quit

● Fraction done reporting

The BOINC API

● boinc_init()● boinc_resolve_filename()● boinc_time_to_checkpoint()● boinc_checkpoint_done()● boinc_finish()

Building apps for BOINC

● Native (C/C++, FORTRAN, Java, Python)– Must call boinc_init()– Win: Visual Studio or MinGW– Mac: Xcode– Unix: gcc

● BOINC wrapper● Vbox wrapper

Anonymous platform mechanism

● Volunteer (not project) supplies app versions

● Purposes:– Unusual platforms or coprocessors– Optimized apps– Security paranoia

BOINC server structure

● MySQL database● Directory structure● Process structure

– Daemons, CGI programs● User/group structure

– apache, boincadm

Creating a BOINC project

● Deployment options– Server VM image (Virtualbox, Debian)– Amazon EC2 image– configure/make

● make_project script

Deploying application versions

● Directory structureapps/ appname1/ 1.0/ windows_intelx86/ (files) windows_intelx86__cuda/ (files) i686-apple-darwin/ (files)● Code signing● update_versions script

Plan class mechanism

● App versions can be tagged with a “plan class”

● app_plan(plan_class, host) function:– Can host run app version of that plan class?– If so, compute resource usage (CPUs, GPUs)– If so, estimate FLOPS

● Examples– vbox32– cuda23– opencl_nvidia_101

Job submission

● Input file staging– upload/download directory hierarchies

● Input, output templates– describe job’s input/output files

● Local job submission– C++, command-line interfaces

● Remote job submission– Web RPCs; C++, PHP interfaces

Job processing

● Validation– Replication– Homogeneous redundancy– Adaptive replication

● Assimilation

Other scheduling features

● Locality scheduling– sticky data files– preferentially send jobs to clients that already

have the needed files● Multi-size applications

– send large jobs to fast devices

Multi-user projects

● Job submitters have accounts● access control● quotas● batch scheduling

– run small batches first– don’t starve large batches– enforce quotas

Server processes

Shared memoryJob cache

scheduler

transitioner

feeder

MySQL DB

validator

assimilator

db_purge

file_deleter

per app

Scaling server performance

● Distribute daemons across machines● Parallelize daemons

– on same or different machines● MySQL server performance● example: SETI@home server

– ~50 machines– 1 million jobs/day

Web interface (public)

● preferences● forums● teams● profiles● leader boards● host, job info● social network features

Contacts

● http://boinc.berkeley.edu● davea@ssl.berkeley.edu● email lists:

– boinc_projects– boinc_dev