There are 3 ways credit gets assigned to a specific work unit.
The first and simpler one, as used by universe@home it's to assign every unit the same value, as they are more or less the same computationally.
The second, as used by many mathematical projects such as yafu it's to assign every "cycle" of the app required a credit count. It also has the advantage of not requiring quorum as the results often can be easily checked by the server.
The third, and the one that concerns me with the fairness, it's the classical one. 2 or more computers will submit their work and credit will get assigned based on run time (nothing to do with completion time, it accurately tracks cpu time used) and the performance reported by the benchmarks. Out of the reported work units, the one who reports the smaller credit decides it.
But that is not exactly fair. When BOINC was created, it was a much simpler time, multi threading cpus barely existed, and i don't think multi-core cpus had even reached the customer market yet. And the applications were also wildly different, seti@home being the king of it.
As such, the benchmarks, whetstone and dhrystone perform a list of simple mathematical problems, take the time it took to execute and report perfomance. Easy, right .
They are not very hard to read so i suggest to take a look there :
https://github.com/BOINC/boinc/blob/master/client/whetstone.cpp
https://github.com/BOINC/boinc/blob/master/client/dhrystone.cpp
But. nowadays both CPUs and workunits are wildly more complex. Many mathematical work units perform much faster on CPUs with big caches, such as the new Ryzens. Projects of the kind of WCG, CSG or TN-GRID are very gated by ram bandwith, yet we have no way to measure it.
If i only run one work unit, with no limiting factors, in an less powerful CPU im reducing the rewards of the other, more powerful CPU, running the maximum capacity, that has to deal with some overhead. All, while not being rewarded for the extra performance.
For that, and of course this would be an extremely slow process because it will have to get incorporated in boinc and then get upgraded, my solution would be to implement more benchmarks. Benchmarks that track the single threaded performance, the top-efficiency performance, and the point of diminishing returns .
For the CPU cache that would be even easier, we could just recycle the cryptonight algorithm from Monero. For ram bandwidth it would be probably the most fair to recycle some project algorithm with arbitrary values.
Another option it's to include customized benchmarks in the projects, either as initial workunits or as a regular occurrence. The good part of this one it's that it would be project independent and would not require any change to Boinc code.