This post is a continuation of a discussion @ilikechocolate started in Researching a FLOP and Energy Based Model for GridCoin Reward Mechanism

Problem

There are big differences in number of credits various projects reward solvers. Gridcoin current solution is to reward each project the same amount of GRCs. As a result, members of popular projects are less rewarded than members of less popular projects.

Source of the problem

Historically, BOINC credit system is based on FLOPS. However, there are other factors affecting application performance, like memory references, cache usage and parallelization of workunits. GPUs may have ~100x higher peak FLOPS than CPUs, however, application efficiency can be as low as 10%-20% for GPUs, or 30% - 50% for CPUs. Usually GPU projects reward a lot more credits than CPU projects. Credit awards are not uniform between BOINC projects and admins of particular projects have freedom of adjusting rewards scheme.

Situation is further complicated by the fact that there are three main types of projects – CPU only, GPU FP64 and GPU FP32.

TL;DR: There is no satisfactory normalization of credit awards between projects.

Fair solution requirements

Credit reward system should fulfil following requirements:

be hardware independent: similar workunits should be rewarded with similar credit

cross- project congruency: the same CPU (or GPU) should earn the same amount of credits on different projects (in properly configured system and adequate resources like RAM)

CPU projects should reward adequate number of credits when compared to GPU projects – the basis could be cost of purchase and cost of running the equipment

Solution

Ideally proper solution would be implemented within BOINC platform itself. Proposed solution can be, however, implemented internally or externally.

Credits would be awarded based on actual work done measured by the time needed to complete work on reference hardware.

reference hardware – a proper, medium to high end hardware should be chosen for each of the three types of projects; for CPU projects it could be Ryzen 7 processor with 16 GB Ram, for GPU FP32 it could be NVIDIA GTX 1060 or 1080 graphic card.

reference hardware (RH) - one hour of run time of the reference hardware would be awarded with one credit on each of eligible projects (for example for Ryzen 7 it would be all CPU-only projects);

To implement this solution outside of the BOINC platform, following adjustments are needed:

reference project (RP)– reference hardware would be awarded with one credit for one hour of run time on BP

extra cross-project normalization – BOINC-credits rewarded by project X (PX) would be multiplied by a proper factor (mPX):

mPX = hourly-credit(RP, RH) / hourly-credit(PX, RH)

Credit earned (per hour) in project X by hardware X:

BOINC-credit = Bc

Credit(PX, HX) = mPX * ( Bc(PX,HX) / Bc(RP,RH) )

Credit earned between superblocks (DC):

DtS – time between superblocks in hours

DC = DtS * Credit(PX, HX)

Example 1 – GPU projects

Let’s asume GTX 1060 is a reference card and it is rewarded in average 17k BOINC-credits on Amicable Numbers. We nomiante Amicable Numbers as a reference (benchmark) project (RP). We award 1 credit for 17k BOINC-credits per hour. Now we want to find a number of credits that GTX 960 should be awarded on [email protected] project. It can achieve 7.6k BOINC-credits at [email protected], thus

Credit unit has been set by definition as 1 per one hour of work of reference hardware on reference project. In fact calculations can be simplified and we can use directly RAC or TCD.

Under condition that RH runs 24/24 and achieves max RAC on both projects:

mPX = RAC(RP, RH) / RAC(PX, RH)

As total RAC for a project may vary due to variable nature of the time work units need to be completed, something like 7-day average might be better choice for mPX.

Credit(PX, HX) = mPX * ( RAC(PX,HX) / RAC(RP,RH) )

Credit([email protected], GTX 960) = 1.4 * ( 182k / 412k) = 0.62

Credit([email protected], GTX 1060) = 1.4 * ( 293k / 412k) = mPX / mPX = 1

GTX 960 would be able to earn up to 24 * 0.62 = 14.88 credits a day, while GTX 1060 24*1 = 24 credits a day.

With the above method cross-project rewards can be normalised and similar hardware will receive similar rewards per hour of completed work.

Example 2 – CPU project

Lets assume Xeon E6545 is a reference processor. It can earn around 430 boinc-credits per hour at [email protected] As it is chosen as a reference processor, it’s earnings in new credits are normalized to 1 per hour. Therefore it can earn as many credits at yoyo as GTX1060 at any FP32 GPU project .

Ryzen 7 1700 has 16 threads and can probably earn around 1000 boinc-credits per hour. This allows for ~56 new credits a day. However, if Ryzen 7 would be chosen as a reference computer it would earn 24 credits a day and mentioned Xeon ust around 10.

Closing words

The main problem with the benchmarking is BOINC system has many variables and we want to reduce it to just one. I think it is impossible to achieve and closest we can get to a satisfactory solution might be to use real reference hardware for benchmarking - as proposed above.

You might also be interested in:

Counting FLOPSs in a FLOPS – part 1

Counting FLOPSs in a FLOPS – part 2