Benchmarks and Credit
BOINC uses a new
credit system rather than simply counting the number of results returned.
BOINC's new unit of credit is called the
Cobblestone, named after Jeff Cobb of the SETI@Home Project.
The amount of credit you will get for each processed work unit depends on a number of factors.
The BOINC application uses two benchmarks, Whetstone and Dhrystone, to measure the floating point and integer speed of your computer.
These benchmark scores are then used in conjunction with the time taken to process a work unit to calculate how much credit your computer will claim for that work unit.
But you are not simply granted the credit you claim. When you return the result to the BOINC project servers together with your claimed credit,
the results are then validated against at least two other results returned by other users.
The highest and lowest claimed credit values are discarded and the average (mean) of the remaining values is awarded to all users.
For three successful results, this is usually just the middle value of the three claimed credits.
Whetstone
The Whetstone benchmark tests double precision floating point operations.
It performs 8 groups of tests multiple times and gives a score based on the number of operations performed divided by the time taken.
The tests include simple addition, subtraction, multiplication and division of floating point numbers together with trigonometric functions
such as sine, cosine, tangent and exponents.
Dhrystone
The Dhrystone Benchmark tests repeated integer operations together with several operating system file handling operations.
How Claimed Credit is Calculated
Claimed credit is calculated as a function of the Whetstone and Dhrystone benchmarks calculated by the
BOINC application multiplied by the time taken in seconds to process the work unit using the following formula:
claimed credit = ([whetstone]+[dhrystone])/1000 * 100 / (2 * secs_per_day) * wu_cpu_time
which can be simplified to the following formula:
claimed credit = ([whetstone]+[dhrystone]) * wu_cpu_time / 1728000
Estimated CPU Time
BOINC only uses the Whetstone benchmark to estimate CPU time needed to process a work unit.
Each work unit downloaded to your machine includes an estimated number of floating point operations.
BOINC divides this by the Whetstone benchmark score to estimate completion time. SETI currently estimates 27.9 trillion (american) floating point operations,
however the actual number of floating point operations varies greatly from one work unit to the next which is why they don't all take the same amount of time.
In addition, this estimation is used to calculate how muck work to download according to your cache settings.
estimated time (Sec) = 27,900,000/Whetstone
Why Estimated CPU Time is Not Very Accurate
The time estimated by BOINC for a work unit to process on your computer is often not very accurate and there are a number of reasons for this.
The estimated time is based on two other estimates, the number of floating point operations required to process the work unit and the
Whetstone benchmark as an indicator of floating point math performance of your computer.
Firstly, SETI estimates the number of floating point operations for it's work units,
but this estimation is the same for each unit where in reality this is not the case. This is the reason some units process significantly quicker than others.
Secondly, BOINC uses the Whetstone benchmark to estimate floating point math performance of your computer.
The Whetstone benchmark tests double precision maths and spends the majority of it's time performing trigonometric functions whereas
SETI performs almost all single precision maths and typically only spends about 20% of it's time performing trigonometric functions.
Thirdly, none of these estimates or benchmarks take into account factors such as memory bandwidth or processor cache size which SETI is hugely dependant
on and can make a significant difference to raw performance.
Finally, the BOINC client and contained benchmark code are not optimized for any specific processor architecture, but rather use generic i686 optimizations
for broad compatibility with a wide range of hardware. This is the reason we can achieve such dramatic improvements by recompiling the BOINC source code with
specific optimizations for our processor architecture (see
here).
