| | 21 | |
| | 22 | == Benefit == |
| | 23 | * Single Scheduling Environment for both High Performance Computing (HPC) resources [Grids] and Volunteer Resources |
| | 24 | * Validation of work units -- Due the homogenous nature of HPC/Grids it is thought that they are more reliable than volunteer resources; however even in these environments data corrupt occurs (system failure, administrative outages, etc) |
| | 25 | |
| | 26 | == Problems == |
| | 27 | There are some pit falls that have been identified by uses BOINC on some Grid computing systems. Most of the problems identified in this session dealt with HPC/Grid Submission Systems and efficient use of Grid resources (allotted grid computing hours). * Problem 1: Scheduled Grid client runs when server has no work |
| | 28 | The client would be idle burning time from the users allotted computer hours. |
| | 29 | * Problem 2: Grid Scheduler kills jobs after time expires |
| | 30 | Even with check pointing data processed on the last WU would be lost. The workspace would be scratched. |
| | 31 | |
| | 32 | == Action Items == |
| | 33 | Incorporate some mechanism into the BOINC client to make it aware to a limited runtime environment. |
| | 34 | Potential Fixes: |
| | 35 | * EndOnNoWork Parameter |
| | 36 | If no work is available from the servers the BOINC client would end instead of deferring communication. |
| | 37 | * MaxWUCount Parameter |
| | 38 | After the max number of WU are reached; the new client would not request new work and then end gracefully. |
