Changes between Version 5 and Version 6 of CreditGeneralized

Timestamp:

Aug 11, 2014, 11:33:54 PM (10 years ago)

Author:

davea

Comment:

--

CreditGeneralized

@@ -13 +13 @@
 (for example, supercomputer performance is measured in FLOPS).
 
-For grant-writing purposes I need to be able say
+Also, for grant-writing purposes I need to be able say
 "BOINC has a peak performance of X PetaFLOPS";
 the current credit system lets me do this.
@@ -28 +28 @@
 One approach is to decide on an "equivalence" between hashes and FLOPs,
 and assign credit based on the current formula.
+
 How many FLOPs is a hash equivalent to?
 One approach is to look at a CPU or GPU, measure its FLOPS and its hashes/sec, and divide.
@@ -37 +38 @@
 With fewer than 1,000 users, BU is granting more credit than the 300,000 users of all other projects combined.
 
-This situation has 2 undesirable consequences:
+This situation has several undesirable consequences:
 
  * Credit no longer measures FLOPs; BOINC's combined average credit
@@ -65 +66 @@
  * '''Storage credit''', measured in byte/seconds (possibly multiplied by availability).
  * '''Network credit''', measured in bytes, the sum of upload and download.
- * '''Project-specific credit'''.
+ * '''Project-defined credit'''.
    Projects can define and grant this however they like.
    For BU, this would be proportional to hashes.
    Other projects, like Wildlife@home, might grant credit for
    a human activity like annotating video.
+
+We'll add APIs so that project validators can grant the new types of credit.
+We'll figure out how to make them cheat-resistant.
 
 The BOINC database will maintain each of these types of credit
@@ -103 +107 @@
 
 My feeling about this is that computing credit should be measure
-'general-purpose' FLOPs, i.e. FLOPs that are usable by most science applications.
+'''general-purpose FLOPs''', i.e. FLOPs that are usable by most science applications.
 FFT FLOPs are not general-purpose.
 So the right thing would be for SETI@home to grant both computing credit
-and project-specific credit.
+and project-defined credit.
 CPU and GPU jobs would be granted both;
-jobs done by ASICs or FPGAs would be granted only project-specific credit.
+jobs done by ASICs or FPGAs would be granted only project-defined credit.
 
 Similarly, BU could grant computing credit for mining jobs done by CPU or GPU;
-but for ASIC jobs it would grant only project-specific credit.
+but for ASIC jobs it would grant only project-defined credit.
 
 Of course this is all subjective and fuzzy;
@@ -117 +121 @@
 some apps don't map well to GPUs.
 But we need to draw a line somewhere,
-and I think we've reached a point where GPUs can be considered general-purpose.
+and I think that, with the advent of OpenCL, GPUs can be considered general-purpose.