![DATASPACE New ‘DATASPACE’ modeled ~LINDA [1] tuplespace A robust communication layer that facilitates data exchanges between tasks Abstract dataspace that acts as (intermediary) for data exchange between tasks Asynchronous one-way communication: Tasks that exchange data need not be alive at the same time Use of process replication to handle volatile nature of nodes Integration with existing volunteer computing systems [1] N. Carriero and D. Gelernter. The s/net’s linda kernel. ACM Trans. Comput. Syst., 4(2):110–129, 1986](https://image.slidesharecdn.com/intertaskcommunicationonvolatilenodes-124198950755-phpapp01/85/Inter-Task-Communication-On-Volatile-Nodes-9-320.jpg)
![PROGRAMMING MODEL Library supports C/C++/Fortran applications One instance of dataspace server per application DATASPACE API int volpex_put ( const char* tag, int tagSize, const void* data, int dataSize) int volpex_get ( const char* tag, int tagSize, void* data, int dataSize) int volpex_read ( const char* tag, int tagSize, void* data, int dataSize) SUPPORTING API int volpex_init ( int argc, char * argv[]) int volpex_getProcId ( void ) int volpex_getNumProc ( void ) void volpex_finish ( void )](https://image.slidesharecdn.com/intertaskcommunicationonvolatilenodes-124198950755-phpapp01/85/Inter-Task-Communication-On-Volatile-Nodes-14-320.jpg)
Inter Task Communication On Volatile Nodes
- 1. INTER-TASK COMMUNICATION ON VOLATILE NODES Masters in Science (Computer Science) Thesis Presented by NAGARAJAN KANNA Advisor: Dr. Jaspal Subhlok Committee: Dr. Edgar Gabriel Dr. Margaret S. Cheung
- 2. OUTLINE INTRODUCTION MOTIVATION DATASPACE PROGRAMMING MODEL IMPLEMENTATION EXPERIMENTS RESULTS CONCLUSION
- 3. OUTLINE INTRODUCTION MOTIVATION DATASPACE PROGRAMMING MODEL IMPLEMENTATION EXPERIMENTS RESULTS CONCLUSION
- 4. INTRODUCTION Parallel & Distributed computing Multi-processor, Multi-core, Multi-computer (Cluster, Grid, Volunteer) Idle desktop computers Immense pool of unused resources Utilized by: BOINC, Condor Volatile nodes Varying computation, communication, storage Availability is unpredictable Handling Volatility Check point/ Restart Process Migration Process Replication
- 5. OUTLINE INTRODUCTION MOTIVATION DATASPACE PROGRAMMING MODEL IMPLEMENTATION EXPERIMENTS RESULTS CONCLUSION
- 6. MOTIVATION Under 1% of available PCs are being harnessed (BOINC generates > 1PetaFLOPS) Ordinary desktop PCs not utilized for running parallel applications Many scientific applications have low degree of communication between processes Lack of a good ‘programming model’ to utilize volatile resources for parallel application
- 7. RELATED WORK BOINC Middleware for Volunteer computing Lack of support for communication parallel programs CONDOR Job scheduler, Support parallel programs Uses check pointing: Not suitable for volatile systems CLUSTERS Expensive: Resources, Maintenance Our Goal: Execution of communicating parallel programs on volatile ordinary desktops
- 8. OUTLINE INTRODUCTION MOTIVATION DATASPACE PROGRAMMING MODEL IMPLEMENTATION EXPERIMENTS RESULTS CONCLUSION
- 9. DATASPACE New ‘DATASPACE’ modeled ~LINDA [1] tuplespace A robust communication layer that facilitates data exchanges between tasks Abstract dataspace that acts as (intermediary) for data exchange between tasks Asynchronous one-way communication: Tasks that exchange data need not be alive at the same time Use of process replication to handle volatile nature of nodes Integration with existing volunteer computing systems [1] N. Carriero and D. Gelernter. The s/net’s linda kernel. ACM Trans. Comput. Syst., 4(2):110–129, 1986
- 10. COMMUNICATION MODEL Client machine running User application Dataspace Server (DSS) 1. Initialize application with DSS info 2. Establish connection with DSS 3. Put data (101, ABCD) 4. Read data (101) 5. Get data (101) 6. Terminate connection with DSS ABCD 101 DATA TAG DATA TAG
- 11. DATASPACE - ‘PUT’ Dataspace Server Client – Replica 1 Client – Replica 2 PUT Meta info from process 1 Tag & Data Status for PUT operation PUT Meta info from process 1 Status - SUCCESS DATA TAG PutCount ProcessId 1 1 PutCount ProcessId
- 12. DATASPACE - ‘READ’ and ‘GET’ Dataspace Server GET (Meta info & Tag) from process 1 Data matching the Tag from Dataspace GET (Meta info & Tag) from process 1 Corresponding Data Client – Replica 1 Client – Replica 2 ABCD 101 DATA TAG GetCount ProcessId 1 1 GetCount ProcessId DATA TAG 2 1 READ Buffer 2 ABCD 1 READ Buffer
- 13. OUTLINE INTRODUCTION MOTIVATION DATASPACE PROGRAMMING MODEL IMPLEMENTATION EXPERIMENTS RESULTS CONCLUSION
- 14. PROGRAMMING MODEL Library supports C/C++/Fortran applications One instance of dataspace server per application DATASPACE API int volpex_put ( const char* tag, int tagSize, const void* data, int dataSize) int volpex_get ( const char* tag, int tagSize, void* data, int dataSize) int volpex_read ( const char* tag, int tagSize, void* data, int dataSize) SUPPORTING API int volpex_init ( int argc, char * argv[]) int volpex_getProcId ( void ) int volpex_getNumProc ( void ) void volpex_finish ( void )
- 15. OUTLINE INTRODUCTION MOTIVATION DATASPACE PROGRAMMING MODEL IMPLEMENTATION EXPERIMENTS RESULTS CONCLUSION
- 16. IMPLEMENTATION Implemented on C/C++ with UNIX TCP Sockets All communications with DSS initiated by client DSS: Single threaded; Uses TCP select to switch Dataspace In memory storage of data Hash table indexed on tag Fixed #entry READ BUFFER to serve processes replicas PUT: Request from replica check only for data size > 2KB On connectivity failure, fixed number of retries with exponentially increasing time interval Dataspace does not differentiate process replicas BOINC : Linking with dataspace library @ compilation
- 17. OUTLINE INTRODUCTION MOTIVATION DATASPACE PROGRAMMING MODEL IMPLEMENTATION EXPERIMENTS RESULTS CONCLUSION
- 18. EXPERIMENTS APPLICATIONS Replica Exchange Molecular Dynamics (REMD) Parallel Sorting by Regular Sampling (PSRS) Sieve of Eratosthenes TEST CASES Micro benchmarks Scalability Redundancy Failure TEST BED Clients: Atlantis Itanium2 1.3GHz dual core with 4GB RAM DSS: AMD Athlon 2.4GHz dual core with 2GB RAM
- 19. REMD A approach for studying the folding thermodynamics of small to modest size proteins in explicit solvent Simulations alternate between phases of conformational sampling and swapping Relatively small communication requirements – Ideally suited for Dataspace API Use of Dataspace Synchronization of processes Store/Read energy values between neighbors Exchange temperate values for next simulation run
- 20. PSRS 27 23 22 16 13 10
- 21. SIEVE OF ERATOSTHENES Simple algorithm for finding all prime numbers up to specified integer Using Dataspace Total set (till specified integer) is divided equally between all the processes MASTER processes identifies candidate prime number and writes it onto the dataspace All other processes reads candidate primer numbers and knocks of all multiples from its list MASTER process collects local sum from all processes
- 22. OUTLINE INTRODUCTION MOTIVATION DATASPACE PROGRAMMING MODEL IMPLEMENTATION EXPERIMENTS RESULTS CONCLUSION
- 23. REMD – Temperature swapping between replicas Application run with 8 replicas (8 temperatures) Parameters: nstlimit=4000; nsteps=5 Processes that swap temperatures at a step have same background color
- 24. REMD: Using Dataspace vs. PERL Disk IO needs to reduced for improving performance
- 25. ROUND TRIP TIME MEASUREMENT Case 1 Case 2 Dataspace Server Start time Dataspace operation Status End time Client process Start time End time PUT (101, ABC) GET (102) GET (101) PUT (102, XYZ) Process 1 Process 2 Dataspace Server ABC 101 DATA TAG DATA TAG XYZ 102 DATA TAG
- 26. RTT: DATASPACE OPERATIONS PUT only marginally faster
- 27. RTT: WITH 2 PROCESSES
- 29. BANDWIDTH / HOP: WITH 2 PROCESSES
- 30. RTT: ‘PUT’ WITH REPLICAS No impact of replicas on Dataspace PUT
- 31. RTT: ‘READ’ WITH REPLICAS
- 32. RTT: ‘GET’ WITH REPLICAS
- 33. BANDWIDTH: ‘PUT’ WITH REPLICAS
- 34. BANDWIDTH: ‘READ’ WITH REPLICAS
- 35. BANDWIDTH: ‘GET’ WITH REPLICAS
- 37. SCALABILITY: SoE
- 38. REDUNDANCY: PSRS
- 39. REDUNDANCY: SoE ~25% increase in execution time with each replica
- 40. FAILURE: PSRS
- 41. FAILURE: SoE Drop in execution time for 2 node failures: ~3%
- 42. PSRS: WITH BOINC & WITHOUT BOINC Variations due to BOINC scheduler
- 43. OUTLINE INTRODUCTION MOTIVATION DATASPACE PROGRAMMING MODEL IMPLEMENTATION EXPERIMENTS RESULTS CONCLUSION
- 44. SUMMARY OF RESULTS REMD: Use for Dataspace API in real world apps Micro benchmarks : On adding replicas PUT: Execution time remains constant READ, GET: Execution time increases with data size Scalability: PSRS & SoE PSRS scales till 32 processes, SoE only till 16processes Redundancy : PSRS & SoE Increase in execution time < 25% with each replica Centralized single threaded server: BOTTLENECK Failure: PSRS & SoE Linear decrease in execution time with increasing failures Integration with BOINC Some impact on the overall application performance
- 45. OUR CONTIBUTION Task parallelism: Dataspace API facilitates data exchange between processes Robustness: Dataspace API supports use of process replication to handle volatility Pluggable: Dataspace API works well with BOINC FUTURE WORK Testing on ordinary desktops Dataspace Implementation: Combining In-memory & Disk Distributed Dataspace Non-blocking dataspace API
- 46. THANK YOU