| | 1 | = BOINC support for science portals = |
| | 2 | |
| | 3 | A '''science portal''' is a web site serving a group of scientists in a particular area. |
| | 4 | In addition to other features, science portals typically offer a facility |
| | 5 | for computing, in which scientists can submit, via a web interface, |
| | 6 | sets of jobs to be run against standard applications. |
| | 7 | Currently these jobs are run on clusters or Grids. |
| | 8 | |
| | 9 | This document proposes additions to BOINC to facilitate using |
| | 10 | a BOINC project as a computing resource for science portals. |
| | 11 | There are two related parts: |
| | 12 | |
| | 13 | * A mechanism for allocating computing resources among scientists |
| | 14 | * A mechanism for handling batches of jobs |
| | 15 | |
| | 16 | == Computing share == |
| | 17 | |
| | 18 | Demand for computing power may exceed supply, |
| | 19 | in which case we need a mechanism for dividing the supply among scientists. |
| | 20 | Assume that every job is associated with a particular BOINC user, |
| | 21 | representing either a scientist or some other organizational entity, |
| | 22 | and that each such user has a numeric '''computing share''' proportional to |
| | 23 | the fraction of the computing resource they should get. |
| | 24 | |
| | 25 | The way in which computing shares are determined is outside the scope, |
| | 26 | but some possibilities are: |
| | 27 | |
| | 28 | * Each scientist attaches their own PCs to the BOINC project, |
| | 29 | and their computing share is the recent average credit of these hosts. |
| | 30 | * Volunteers attached to the project can assign shares of their resource |
| | 31 | to scientists, and a scientist's overall share is the sum of these, |
| | 32 | weighted by the volunteer average credit. |
| | 33 | * A scientist's share is increased if they contribute to the portal, |
| | 34 | e.g. by participating in the message boards. |
| | 35 | |
| | 36 | What are the precise semantics of computing share? |
| | 37 | Ideally this should accommodate two classes of scientists: |
| | 38 | |
| | 39 | * '''Throughput-oriented''': those who have an infinite stream of jobs. |
| | 40 | They want maximum throughput, and don't care about the turnaround times |
| | 41 | of individual jobs. |
| | 42 | |
| | 43 | * '''Latency-oriented''': those who occasionally have large batches of jobs, |
| | 44 | and who want the entire batch to be finished fast. |
| | 45 | Such a user, for example, might not submit any jobs for a month, |
| | 46 | then submit a batch that takes a day to complete using the entire resource. |
| | 47 | |
| | 48 | To accommodate both extremes, |
| | 49 | we propose a system in which each user has an associated '''debt''', |
| | 50 | i.e. how much computation the system owes to that user. |
| | 51 | |
| | 52 | A user's debt continually increases at a rate equal to their computing share. |
| | 53 | Debt is capped at a value corresponding to, say, |
| | 54 | use of the entire computing resource for 1 week. |
| | 55 | |
| | 56 | When a job completes (successfully or not) its user's debt is decremented |
| | 57 | by the amount of computing done |
| | 58 | (more precisely, but the amount of computing that would have been done |
| | 59 | by the job's resources running at peak speed for the job's elapsed time). |
| | 60 | |
| | 61 | In this scheme, latency-oriented user can build up a debt that allows their |
| | 62 | batches (if they are sufficiently infrequent) to get the full computing resource |
| | 63 | and finish as fast as possible. |
