Yes, the basic proposal for updating the BOINC Credit System is sound ...
but due the basic fact that GPUs that are so like CPUs ... it would seem
that a complex number or a tuple for "Computing Credit" .
The whole BitCoin minting with ASICs issue that is forcing this long overdue
distinction -- is caused by the fact that BOINC's job of measuring CPU
performance with BINARY MATH OPERATIONS was dismal from the beginning.
Binary Math Operations on a CPU are not really Integer Math, but still
subject to Integer Math control logic. Unlike Floating Point Math that
requires some overhead to keep the numbers sane (up to 2% of CPU time for
some kinds of algorithms {climate prediction?, protein folding?} , but
usually 0.1% to 0.5% of CPU time) ... binary math has no such overhead.
Binary Math registers also vary in size, and so do the supporting
instruction sets. Performance varies wildly.
? ! ?
In any case : There was no BOINC benchmark that measured a CPUs (or GPUs)
ability to do binary math operations.
There is one existing project that was affected by this quirk before
BitCoins came around :
Rainbow Table Generation (something, something ... I forget its name )
!
YES, the basic idea below will fix the problem.
NO, it will not be adequately workable unless the Computing Credit becomes a
Vector or Tuple.
!
MP DSN @ H
PS :
Do some background research to make certain that the BOINC implementation is
not like anything patented. The possibility for conflict here is slim, but
there are 2 or 3 other distributed computing systems like BOINC that are
private or closed source.
--------------------------------------------------------------------------------
So, I propose that, rather than trying to shoehorn everything into one
number, we keep track of multiple types of credit. In particular, I propose
4 types:
Computing credit: general-purpose FLOPs, i.e. what we have now.
Storage credit, measured in byte/seconds (possibly multiplied by
availability).
Network credit, measured in bytes, the sum of upload and download.
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 for each
host, user, and team. It will store both total and recent average for each
type.
Wherever we show credit on project web sites - leader boards, user and team
pages, etc. - we'll show one or more credit types; the choice of types will
be configurable by the project.
The new types of credit will be included in the XML statistics files
exported by projects. Statistics sites (such as BOINCStats) will be extended
to show the new types of credit.
--------------------------------------------------------------------------------
-----Original Message-----
From: David Anderson
Sent: 11 August 2014 23:48
Subject: [boinc_projects] Credit revisited
A proposal for extending BOINC's credit system to handle
special-purpose computing (such as BitCoin mining)
as well as storage and communication:
http://boinc.berkeley.edu/trac/wiki/CreditGeneralized
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
