Let's talk about credit, benchmarks, and how i do believe they may need an overhaul.
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.
I remember a while ago reading an analysis by BOINC people trying to solve the same problems: https://boinc.berkeley.edu/trac/wiki/CreditNew
I don't remember all the details now, but it looks like the new (third) credit system makes some progress. It's kinda complicated, so I'm not sure if I want to go through it again now. Just curious if you had come across it before.
I found that article a while ago, there is a long running discussion about it here .
One thing that is clear from the CreditNew discussion is that established projects are unlikely to change their credit granting systems in a hurry. Changing an established program for cross project "fairness" isn't a high priority and although it would be convenient for Gridcoin if granted BOINC credit were consistent between projects it doesn't look like there will be a standard for granting of BOINC credit anytime soon.
I have wondered if it would be feasible for the Gridcoin network to replicate the CreditNew function based on the BOINC statistics that are already collected for mining reward calculations, let me know if this has already been discussed previously.
Wait, so how many projects implement CreditNew? Given its complexity, I guess it makes sense that its adoption wouldn't be widespread.
Worthwhile thought. I remember some discussions from a couple months ago proposing various new ways to calculate magnitude (e.g. using network-averaged conversion factors to normalize across device types), but I don't think these explicitly mentioned CreditNew.
I have only done some very casual research into the topic, I guess a search on open source code repositories would show if a project were using the suggested code as it appears on the CreditNew wiki page.
I only mention CreditNew because it is a method for credit normalization that has already been published. Calculation of the conversion factors could be adapted based on other statistics the network has recorded, I am just interested to know if the CreditNew code would be a feasible code base for development of a gridcoin credit normalization algorithm.
https://steemit.com/gridcoin/@ilikechocolate/researching-a-flop-and-energy-based-incentive-compatible-model-for-gridcoin-reward-mechanism-pseudocode-included
Uncomplicated article. I learned a lot of interesting and cognitive. I'm screwed up with you, I'll be glad to reciprocal subscription))
You have very interesting thoughts there @ivanviso I would disagree with some of them. Yes, I would love to get the higher credit per work unit as possible, but my hardware is not the newest in the market or a couple of generations off. I understand for those people that have the best hardware they are suffering now because they do not get the all of their credits when they are crunching projects that use the third method you mention. But, if projects change their methods of credits assigned to the one you suggest what would happen to the people that use hardware that is not up to date. They would have to spend funds on hardware that they do not have or continue falling behind. I think the methods to assign credits should be left the way they are because they help everyone. And, I would like to remind you that this is a volunteer computing network, so when people volunteer computer cycles to the network is what they have in regards to hardware because they want to help scientific research. But, for those people that have the high-end hardware, some projects utilize that high-end hardware to their fullest. So, for those people, they should choose those projects and leave the rest to people that do not have high-end hardware. And, everyone will have projects for their hardware to crunch.
If I misunderstood your point, I apologize, but I think that is why we have diverse ways of getting credits because not everyone will have the latest hardware or the same hardware.
It's unfair to everyone in this case . If I have a cpu half the powerful than the other one, complete one work unit in the same time, I will still get the reward proportional to that cpu , and also force the other one to get it.
True, I agree with you. But, my point, that the person has the choice to go to a project that has a more balance system. I would have like to see how many projects use which system to reward credits. And, then compare what cpu's and gpu's are running those projects. I believe that diversity is always good.
How does the CreditNew function factor in this discussion?
As I understand, a project that implements this credit granting method will be gathering statistics on each type of hardware (or even each host) and normalizing credit based on an constantly evolving benchmark.