Volpex@Home: Difference between revisions
fix links and images |
add image |
||
| Line 62: | Line 62: | ||
=== VolpexMPI === | === VolpexMPI === | ||
[[File:Remd.jpg|alt=inCell@Home is an application of Volpex|thumb|445x445px|inCell@Home is an application of Volpex; this project simulates how proteins behave and make function in a real cell-like environment which can be applied in biological drug design.]] | |||
'''VolpexMPI''' was a subset implementation of the [[wikipedia:Message_Passing_Interface|Message Passing Interface]] (MPI) standard tailored to volatile nodes. Ordinary message-passing exchanges were converted into asynchronous Put/Get operations, and process replication provided robustness. The key fault-tolerance technique was fully distributed, sender-based message logging, which let a restarted or replacement replica reconstruct the messages it needed without a central checkpoint server.<ref name="leblanc2009" /> A later, portable variant called VolpexPyMPI was written in [[wikipedia:Python_(programming_language)|Python]], ran on both Linux and Windows, and accepted user-level MPI programs written in C or [[wikipedia:Fortran|Fortran]], trading some performance for ease of use and portability across heterogeneous hardware and operating systems.<ref name="leblanc2010ccgrid">{{cite conference |last1=LeBlanc |first1=Troy P. |last2=Subhlok |first2=Jaspal |last3=Gabriel |first3=Edgar |title=A High-Level Interpreted MPI Library for Parallel Computing in Volunteer Environments |book-title=2010 10th IEEE/ACM International Conference on Cluster, Cloud and Grid Computing (CCGrid) |date=2010 |pages=405-414 |doi=10.1109/CCGRID.2010.85 |url=https://ieeexplore.ieee.org/document/5493405}}</ref> | '''VolpexMPI''' was a subset implementation of the [[wikipedia:Message_Passing_Interface|Message Passing Interface]] (MPI) standard tailored to volatile nodes. Ordinary message-passing exchanges were converted into asynchronous Put/Get operations, and process replication provided robustness. The key fault-tolerance technique was fully distributed, sender-based message logging, which let a restarted or replacement replica reconstruct the messages it needed without a central checkpoint server.<ref name="leblanc2009" /> A later, portable variant called VolpexPyMPI was written in [[wikipedia:Python_(programming_language)|Python]], ran on both Linux and Windows, and accepted user-level MPI programs written in C or [[wikipedia:Fortran|Fortran]], trading some performance for ease of use and portability across heterogeneous hardware and operating systems.<ref name="leblanc2010ccgrid">{{cite conference |last1=LeBlanc |first1=Troy P. |last2=Subhlok |first2=Jaspal |last3=Gabriel |first3=Edgar |title=A High-Level Interpreted MPI Library for Parallel Computing in Volunteer Environments |book-title=2010 10th IEEE/ACM International Conference on Cluster, Cloud and Grid Computing (CCGrid) |date=2010 |pages=405-414 |doi=10.1109/CCGRID.2010.85 |url=https://ieeexplore.ieee.org/document/5493405}}</ref> | ||
| Line 68: | Line 68: | ||
=== Volpex Simulation === | === Volpex Simulation === | ||
A third thrust, '''Volpex Simulation''', built a virtual model of a real-world desktop grid, complete with realistic node and network characteristics, to estimate how parallel applications would perform under different network parameters and configurations before deployment.<ref name="about" /> Using a measurement and simulation tool chain on the NAS benchmarks, the researchers found that running on a realistic volunteer campus pool produced slowdowns by factors of roughly <math>2</math> to <math>10</math> compared with a dedicated cluster, depending on the benchmark code.<ref name="nandagudi2012">{{cite conference |last1=Nandagudi |first1=Girish |last2=Subhlok |first2=Jaspal |last3=Gabriel |first3=Edgar |last4=Gimenez |first4=Judit |title=Estimation of MPI Application Performance on Volunteer Environments |book-title=Euro-Par 2011: Parallel Processing Workshops, Lecture Notes in Computer Science |volume=7155 |date=2012 |pages=511-520 |publisher=Springer |doi=10.1007/978-3-642-29737-3_56 |url=https://link.springer.com/chapter/10.1007/978-3-642-29737-3_56}}</ref> | A third thrust, '''Volpex Simulation''', built a virtual model of a real-world desktop grid, complete with realistic node and network characteristics, to estimate how parallel applications would perform under different network parameters and configurations before deployment.<ref name="about" /> Using a measurement and simulation tool chain on the NAS benchmarks, the researchers found that running on a realistic volunteer campus pool produced slowdowns by factors of roughly <math>2</math> to <math>10</math> compared with a dedicated cluster, depending on the benchmark code.<ref name="nandagudi2012">{{cite conference |last1=Nandagudi |first1=Girish |last2=Subhlok |first2=Jaspal |last3=Gabriel |first3=Edgar |last4=Gimenez |first4=Judit |title=Estimation of MPI Application Performance on Volunteer Environments |book-title=Euro-Par 2011: Parallel Processing Workshops, Lecture Notes in Computer Science |volume=7155 |date=2012 |pages=511-520 |publisher=Springer |doi=10.1007/978-3-642-29737-3_56 |url=https://link.springer.com/chapter/10.1007/978-3-642-29737-3_56}}</ref> | ||
| Line 86: | Line 84: | ||
== How volunteers participated == | == How volunteers participated == | ||
[[File:BOINC project architecture.png|thumb|alt=A diagram of the BOINC client-server architecture showing a server feeding work to many volunteer clients over the Internet|The BOINC client-server architecture that Volpex extended with its Dataspace communication layer.<ref name="rohit2011" />|360x360px]] | |||
Volunteers attached their BOINC client to the project's URL, and the BOINC server recruited hosts for each parallel job. Because a communicating job needs a fixed number of processes running at the same time, the server waited until enough hosts had been recruited and then started them together; recruited hosts that were waiting their turn temporarily idled and released the CPU rather than running the task.<ref name="faq" /> Some hosts were designated as spare nodes that stood by to replace a failed node mid-job.<ref name="faq" /> | Volunteers attached their BOINC client to the project's URL, and the BOINC server recruited hosts for each parallel job. Because a communicating job needs a fixed number of processes running at the same time, the server waited until enough hosts had been recruited and then started them together; recruited hosts that were waiting their turn temporarily idled and released the CPU rather than running the task.<ref name="faq" /> Some hosts were designated as spare nodes that stood by to replace a failed node mid-job.<ref name="faq" /> | ||