Changes between Version 1 and Version 2 of CreditProposal
- Timestamp:
- Jan 9, 2008, 2:31:12 PM (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
CreditProposal
v1 v2 1 1 = Proposal for a new credit system = 2 2 3 This is a discussion of (and tentative proposal for) 4 a new credit system for BOINC. 3 This is a tentative proposal for a new credit system for BOINC. 5 4 6 5 == Requirements == 7 6 8 7 * 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 .8 * 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 (however, volunteers with unusual computers should have an incentive to select projects that need such resources). 10 9 11 10 == Types of utility == … … 29 28 * 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 29 * 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.30 * Normalization rule: for each project, the average of C(H) over all hosts participating in BOINC must be about 100. 32 31 * Accounting rule: the credit granted by a project P cannot exceed the sum over hosts H of 33 32 {{{ … … 49 48 50 49 * BOINC doesn't currently have code to measure memory bandwidth or cache sizes; we'd need to develop this. 50 * How should credit functions be represented (e.g., as a data structure? a PHP function?). 51 * What should the default credit function be? What tools can we provide to projects to let them develop appropriate credit functions easily? 52 * As computers become faster and bigger, credit functions will have to change in order to continue to satisfy the normalization rule. 51 53 * 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 54 * 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 55 * 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 56 * 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? 57 * This proposal doesn't say anything about the last 3 types of utility.
