Volpex@Home: Difference between revisions

Al Piskun (talk | contribs)
fix links and images
Al Piskun (talk | contribs)
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 ===
[[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]]


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" />