Volunteer computing

From Infogalactic: the planetary knowledge core
Jump to: navigation, search

Lua error in package.lua at line 80: module 'strict' not found. Volunteer computing is a type of distributed computing in which computer owners donate their computing resources (such as processing power and storage) to one or more "projects".

History

The first volunteer computing project was the Great Internet Mersenne Prime Search, which was started in January 1996.[1] It was followed in 1997 by distributed.net. In 1997 and 1998, several academic research projects developed Java-based systems for volunteer computing; examples include Bayanihan,[2] Popcorn,[3] Superweb,[4] and Charlotte.[5]

The term "volunteer computing" was coined by Luis F. G. Sarmenta, the developer of Bayanihan. It is also appealing for global efforts on social responsibility, or Corporate Social Responsibility as reported in a Harvard Business Review[6] or used in the Responsible IT forum.[7]

In 1999, the SETI@home and Folding@home projects were launched. These projects received considerable media coverage, and each one attracted several hundred thousand volunteers.

Between 1998 and 2002, several companies were formed with business models involving volunteer computing. Examples include Popular Power, Porivo, Entropia, and United Devices.

In 2002, the Berkeley Open Infrastructure for Network Computing (BOINC) project was founded at University of California, Berkeley Space Sciences Laboratory, funded by the National Science Foundation. BOINC provides a complete middleware system for volunteer computing, including a client, client GUI, application runtime system, server software, and software implementing a project web site. The first project based on BOINC was Predictor@home, based at the Scripps Research Institute, which began operation in 2004. Soon thereafter, SETI@home and ClimatePrediction.net began using BOINC. A number of new BOINC-based projects were created over the next few years, including Rosetta@home, Einstein@home, and AQUA@home. In 2007, IBM World Community Grid switched from the United Devices platform to BOINC.[8]

Middleware for volunteer computing

The client software of the early volunteer computing projects consisted of a single program that combined the scientific computation and the distributed computing infrastructure. This monolithic architecture was inflexible. For example, it was difficult to deploy new application versions.

More recently, volunteer computing has moved to middleware systems that provide a distributed computing infrastructure independent from the scientific computation. Examples include:

Most of these systems have the same basic structure: a client program runs on the volunteer's computer. It periodically contacts project-operated servers over the Internet, requesting jobs and reporting the results of completed jobs. This "pull" model is necessary because many volunteer computers are behind firewalls that do not allow incoming connections. The system keeps track of each user's "credit", a numerical measure of how much work that user's computers have done for the project.

Volunteer computing systems must deal with several issues involving volunteered computers: their heterogeneity, their churn (the tendency of individual computers to join and leave the network over time), their sporadic availability, and the need to not interfere with their performance during regular use.

In addition, volunteer computing systems must deal with problems related to correctness:

  • Volunteers are unaccountable and essentially anonymous.
  • Some volunteer computers (especially those that are overclocked) occasionally malfunction and return incorrect results.
  • Some volunteers intentionally return incorrect results or claim excessive credit for results.

One common approach to these problems is replicated computing, in which each job is performed on at least two computers. The results (and the corresponding credit) are accepted only if they agree sufficiently.

Drawbacks for participants

  • Increased power consumption: A CPU generally uses more electricity when it is active compared to when it is idle. Additionally, the desire to participate may cause the volunteer to leave the PC on overnight or disable power-saving features like suspend. Furthermore, if the computer cannot cool itself adequately, the added load on the volunteer's CPU can cause it to overheat.
  • Decreased performance of the PC: If the volunteer computing application runs while the computer is in use, it may impact performance of the PC. This is due to increased usage of the CPU, CPU cache, local storage, and network connection. If RAM is a limitation, increased disk cache misses and/or increased paging can result. Volunteer computing applications typically execute at a lower CPU scheduling priority, which helps to alleviate CPU contention.[9]

These effects may or may not be noticeable, and even if they are noticeable, the volunteer might choose to continue participating. However, the increased power consumption can be remedied to some extent by setting an option to limit the percentage of the processor used by the client, which is available in some client software.

See also

References

  1. Lua error in package.lua at line 80: module 'strict' not found.
  2. Lua error in package.lua at line 80: module 'strict' not found. ISBN 978-3-540-64216-9 (print) ISBN 978-3-540-69704-6 (online)
  3. Lua error in package.lua at line 80: module 'strict' not found.
  4. Lua error in package.lua at line 80: module 'strict' not found.
  5. Lua error in package.lua at line 80: module 'strict' not found.
  6. Lua error in package.lua at line 80: module 'strict' not found.
  7. Lua error in package.lua at line 80: module 'strict' not found.
  8. Lua error in package.lua at line 80: module 'strict' not found.
  9. Lua error in package.lua at line 80: module 'strict' not found.

External links