| | 1 | = Proposal for a new credit system = |
| | 2 | |
| | 3 | This is a discussion of (and tentative proposal for) |
| | 4 | a new credit system for BOINC. |
| | 5 | |
| | 6 | == Requirements == |
| | 7 | |
| | 8 | * The system should reflect how much "utility" volunteers provide to projects. There are many types of utility (see below). Projects should be able to define utility however they want. |
| | 9 | * The system should limit the amount of credits that projects can grant, so that there will be no incentive for average volunteers to select projects based on credit. |
| | 10 | |
| | 11 | == Types of utility == |
| | 12 | |
| | 13 | Possible types of utility: |
| | 14 | |
| | 15 | * Computation (FP, integer, or mixed) without tight deadlines (this is typical of most current projects). |
| | 16 | * Computation with a tight latency bound (minutes or hours). |
| | 17 | * Computation that needs a large amount of RAM. |
| | 18 | * Computation that needs a large amount of storage. |
| | 19 | * Storage (e.g. GB/day) |
| | 20 | * Storage, with network bandwidth and/or availability requirements |
| | 21 | * Network bandwidth (e.g. web crawling) |
| | 22 | * Network bandwidth at particular times of day (e.g. Internet performance study) |
| | 23 | * Deployment on a wide range of computer types (e.g. studies of computer usage) |
| | 24 | * Computation with human "steering" |
| | 25 | * Human activity (e.g. Stardust@home-type projects) |
| | 26 | |
| | 27 | == Proposal == |
| | 28 | |
| | 29 | * Computers are described by a set of parameters (FP and int benchmarks, #CPUs, cache sizes, memory bandwidth, available RAM, available disk, presence of particular GPUs, network bandwidth, available fraction, connected fraction, maybe others). |
| | 30 | * Each project P publishes a "credit function" C(H) specifying, for a host H with given parameters, how much credit per day would be granted if H is attached exclusively to P. |
| | 31 | * Normalization rule: the average of C(H) over all hosts participating in BOINC must be about 100. |
| | 32 | * Accounting rule: the credit granted by a project P cannot exceed the sum over hosts H of |
| | 33 | {{{ |
| | 34 | RS(H, P)*C(H) |
| | 35 | }}} |
| | 36 | where RS(H, P) is the fractional resource share of H's attachment to P. |
| | 37 | |
| | 38 | The normalization and accounting rules would be evaluated by cross-project statistics sites. |
| | 39 | |
| | 40 | == Examples == |
| | 41 | |
| | 42 | * Computational projects would have to derive a credit function based on how fast various types of computers run their applications (and how much they value each application). We can supply automated tools for this. |
| | 43 | * Suppose a project's application needs at least 16 GB RAM. Its credit function would be zero for hosts with < 16 GB RAM. Its value for hosts with at least 16 GB would be limited by the normalization rule. |
| | 44 | * For a storage-only projects, C(H) would be proportional to available disk space (possibly with some additional consideration for network bandwidth etc.). |
| | 45 | * Using the published credit functions, it would be possible to develop a "credit maximizer" web site, where users can enter the parameters of their computer, and it tells them how much credit/day each project would give them. |
| | 46 | * Similarly, it would be possible to develop a web site that tells users how much additional credit/day they could get by adding more disk/RAM/network bandwidth etc. to an existing computer. |
| | 47 | |
| | 48 | == Questions and comments == |
| | 49 | |
| | 50 | * BOINC doesn't currently have code to measure memory bandwidth or cache sizes; we'd need to develop this. |
| | 51 | * Credit can no longer be used as a basis for FLOPS estimates; we'll need something else for that purpose (or keep around the existing credit system and use it only to estimate FLOPS). |
| | 52 | * Suppose a project's application needs X GB of RAM, and there is only one host in the BOINC population with that much RAM. Then its credit per day for that host can be 100N, where N is the size of the population. In other words, that computer can get as much credit as all other computers combined. Is this desirable? |
| | 53 | * The accounting rule doesn't take into account non-competing projects. E.g. suppose project A uses only CPU and project B uses only disk. If hosts attach to both projects with equal resource shares, the projects will be limited to issuing 50 credits/day on the average. |
| | 54 | * Suppose a project uses a resource that no other project wants (e.g. QCN uses the accelerometer found in some laptops). Should the project be able to allocate the full 100 credits/day on average? |
