| | 1 | - why should boinc use grids |
| | 2 | |
| | 3 | - resources in general more secure and owners trusted |
| | 4 | - can be used for result verification |
| | 5 | |
| | 6 | - resources are more stable, available, and often underutilized |
| | 7 | - easier to support low-latency jobs for |
| | 8 | example |
| | 9 | |
| | 10 | - resources often connected by high bandwidth links |
| | 11 | - could support data-intensive or data-parallel jobs |
| | 12 | |
| | 13 | - environment (in terms of software/libraries) |
| | 14 | tends to be more homogeneous and configurable |
| | 15 | |
| | 16 | - easy to run the boinc client on a cluster and |
| | 17 | supercomputers by statically compiling a |
| | 18 | stand-alone client |
| | 19 | |
| | 20 | - examples: condor pools that run boinc jobs when |
| | 21 | their machines are not in use |
| | 22 | |
| | 23 | - leverage existing grid software |
| | 24 | job submission often simpler with web portals |
| | 25 | |
| | 26 | - why should grids use boinc |
| | 27 | |
| | 28 | - order of magnitude more computing power and storage |
| | 29 | at fraction of the cost |
| | 30 | |
| | 31 | - many grid jobs are already task parallel, |
| | 32 | |
| | 33 | - challenge |
| | 34 | - lack of mechanisms and standards to allow |
| | 35 | a job submitted on a grid to run easly in |
| | 36 | boinc |
| | 37 | - cannot rely on the existance of a software stack |
| | 38 | - concept of an individual user or |
| | 39 | job (and access rights) in BOINC |
| | 40 | - credit accounting for these jobs |
