= Proposal for a new credit system =

This is a discussion of (and tentative proposal for)
a new credit system for BOINC.

== Requirements ==

 * 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.
 * 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.

== Types of utility ==

Possible types of utility:

 * Computation (FP, integer, or mixed) without tight deadlines (this is typical of most current projects).
 * Computation with a tight latency bound (minutes or hours).
 * Computation that needs a large amount of RAM.
 * Computation that needs a large amount of storage.
 * Storage (e.g. GB/day)
 * Storage, with network bandwidth and/or availability requirements
 * Network bandwidth (e.g. web crawling)
 * Network bandwidth at particular times of day (e.g. Internet performance study)
 * Deployment on a wide range of computer types (e.g. studies of computer usage)
 * Computation with human "steering"
 * Human activity (e.g. Stardust@home-type projects)

== Proposal ==

 * 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).
 * 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.
 * Normalization rule: the average of C(H) over all hosts participating in BOINC must be about 100.
 * Accounting rule: the credit granted by a project P cannot exceed the sum over hosts H of
{{{
RS(H, P)*C(H)
}}}
 where RS(H, P) is the fractional resource share of H's attachment to P.

The normalization and accounting rules would be evaluated by cross-project statistics sites.

== Examples ==

 * 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.
 * 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.
 * For a storage-only projects, C(H) would be proportional to available disk space (possibly with some additional consideration for network bandwidth etc.).
 * 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.
 * 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.

== Questions and comments ==

 * BOINC doesn't currently have code to measure memory bandwidth or cache sizes; we'd need to develop this.
 * 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).
 * 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?
 * 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.
 * 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?