BOINC roadmap 2019
The results of a discussion 9/19 between me, Kevin Reed, and Matt Blumberg. This is a wish list more than a road map; our current resources may not suffice to do any of these. Items are listed in (roughly) decreasing priority. Some of these have Github issues: https://github.com/BOINC/boinc/issues/3417
High priority items
These limit our ability to attract volunteers and scientists.
Android 10 problem
The current BOINC client doesn’t work on Android 10 because of changes to background process mechanisms.
Lower VM process priority
Make VMs run at low process priority. VBox used to have this feature, but now it doesn’t. Either get them to restore it, or make our own fork of VBox.
This is critical. Without VM apps, setting up projects is too hard. Without low priority, VMs degrade computer performance unacceptably.
Eliminate GPU streaming glitches
Goal: eliminate glitches in streaming video playback because of GPU usage.
- Figure out how to detect when video playback is happening. Possible proxy: the topmost window is full screen (this would handle video games too)
- Add default preference for not using GPU during video playback
Goal: avoid excessive fan noise
- Research how to get CPU/GPU/system fan speeds and estimating noise.
- Add mechanism for throttling computation (CPU or GPU) to limit additional fan noise
Goal: use GPUs on Android. This could increase the FLOPS per device by a factor of 100 or more.
- Research the availability of OpenCL on current phones
- Study heat and power issues in using GPUs on phones and tablets
- Get an existing OpenCL app (say, SETI@home) to work on Android.
- Develop a cookbook for building OpenCL apps for Android/ARM
Goal: improve the experience of a scientist “kicking the tires” with BOINC. The first step is to define a target “out-of-box experience” (OOBE). For example: suppose a scientist has a Linux system and a Linux executable. They have minimal programming and sysadmin skills. We should provide a “cookbook” so that within one hour (say)
- They have a BOINC project to which clients can attach
- They can easily process jobs, using Win/Mac/Linux clients, using a cmdline interface
- They can register with Science United and get 100-1000 hosts
- The project can be seamlessly extended to handle other app versions, to support validation and scriptable job submission and assimilation, etc
Longer term, we need to simplify all aspects of the BOINC server, e.g.:
- Eliminate the need to specify things like FLOP counts and RAM usage; figure these out dynamically.
- Reduce the need to write XML
- Allow admins to manage as much as possible via a web interface
Broaden VM support
Goal: make it easier and more efficient to use VM apps.
- Research VM systems other than VBox: HyperV (Win), KVM (Linux, Mac), VMWare. Do they support snapshots? Process priority control? GPU usage? What is their market share and outlook? Can we get a license for VMWare?
- Add detection of relevant VM systems to the BOINC client
- Extend the VM wrapper to support other VM systems
- Move VM control into the BOINC client, eliminating the need for a wrapper. The client could then check for the BIOS enabling of VM instructions directly
- Implement a “single VM” architecture in which there’s one VM per host, and applications (possibly from different projects) run in containers inside it. Possibly one VM for CPU apps, one for GPU apps
- Research supporting WebAssembly (https://webassembly.org/) applications, possibly using a wrapper
Integrate with other high-throughput computing systems
Goal: make it easy/possible to use BOINC to supply computing resources to existing job submission systems.
- Survey existing HTC systems used for scientific computing (Condor, Slurm, Spark, Jetstream) and with HTC front ends (Jupyter, Agave, Pegasus). Get an idea of the level of usage of each of them, the level of difficulty of developing an “adapter” that replaces the system’s back end with BOINC, and the level of interest among users of the system in doing so
- Develop “adapters” for one or more systems
- Publicize BOINC, and these adapters, to existing users of the systems. E.g. give a talk at the Condor conference
Goal: further simplify the startup experience by maintaining a “library” of widely-used apps (e.g. Autodock, Charm, Gromacs) so that scientists don’t have to supply their own executables.
- Identify a set of apps to support
- Maintain BOINC-ready versions of these apps (native or VM) for various platforms
- Design a mechanism allowing a project to install these apps on their server
How to do code signing? The provider of the library app will sign with their private key and publish their public key. A project that uses their app would sign the public key of the provider and the client would then trust the library app via the chain of signed keys.
Partner with companies and universities
Goal: increase technical and promotional partnerships with tech companies (Microsoft, Intel, AMD, Google, VMWare, cell phone makers and service providers, etc.) and with universities.
Idea: create an “advisory board” of big names:
- Someone from NSF
- Someone with supercomputing connections (Fran Berman? TACC?)
- High-profile scientists (CERN? Bruce Allen. Myles Allen. David Baker)
Identify high-level people in companies to approach (possibly with help from advisory board).
Apply to Google Summer of Code next year.
Identify academic researchers connected to any aspect of BOINC (e.g. power issues) and try to interest them in BOINC.
Try to get university IT departments interested in running BOINC on their resources (desktop or data center).
Low priority items
Goal: measure and increase the FLOPS/Watt of BOINC computing.
- Research the “power states” (voltage, clock rate) of current Intel and AMD CPUs. For each state, what is the power consumption, and what is the FLOPS? Peter Hanappe did some research on this several years ago; I’m sure there are lots of papers about it. Also investigate the impact these “power states” have on heat generation and the need for systems to increase fan speed (and therefore noise). Could this also solve user retention issues around heat generation and fan noise?
- What mechanisms do OSs (Win/Mac/Linux) have for getting and setting power state?
- Modify the BOINC client to offer a “maximize FLOPS/Watt” preference
Goal: lay the groundwork for improving the UI/UX, including GUI and web parts.
Do a focus group to study
- Recruitment: what makes people want to sign up, Signup process, Retention: what makes people stop participating
- Look at Adobe tool for mocking up GUIs
- Change/replace GUI and web interfaces
Cross-project resource allocation
Goal: maximize global throughput while honoring volunteer prefs for science areas. E.g. suppose someone wants to support cancer research, but their computer has a GPU that’s better for physics. Use their computer for physics, freeing up other computers to do cancer.
Science United more or less does this.
Or: do something using blockchain for accounting.
Hardware-supported secure computing
Study hardware mechanisms like Intel SGX, ARM Trustzone, AMD SEV. This would solve problems of data privacy and result validation. Note: Ankr is doing this. Not sure if their stuff is open source.
References on CPUs and power, from Germano Massullo:
: Volume 3 paragraph 14.4 "hardware-controlled perfomance states
(HWP)" https://software.intel.com/sites/defaul ... -3abcd.pdf
: "AMD Ryzen Processor Normal Operation"
https://download.amd.com/documents/AMD- ... -Guide.pdf
: Chapter 17, "Hardware Performance Monitoring and Control"
: "Balancing Power and Performance in the Linux Kernel" - Kristen
Accardi https://events.static.linuxfound.org/si ... e_2015.pdf
: "Understanding the dynamic nature of modern processors in
preparation for exascale computing" - Pablo Llopis
https://www.slideshare.net/slideshow/em ... LpZ14nDtlx