You are viewing a single comment's thread from:

RE: Update to the Gridcoin Reward Mechanism Proposal

in #gridcoin • 5 years ago

This is a really cool idea, even if it could take away incentives to explore/crunch lesser known projects. Ideally we could even use this sort of system to encourage people to retire super old systems.
(e.g. there are still 450 Pentium 4 systems actively running BOINC)

However, there are bunch of annoying issues that I've come across while working on QuickMag, that could present serious problems for calculating M fairly.

Potential Issues:

  • BOINC CPU credit is based on your whetstone FLOPS score * task run time. However, this doesn't take advantage of more modern CPU instruction sets (AVX and its successors) that do significantly more work per cycle.
  • Extending M to account for GPUs is going to be a serious challenge. The coprocs field is a mess, older AMD GPUs are basically indistinguishable from each other, and multi GPU systems in general.
  • Need to still be able to account for variation in performance due to different memory configurations/modifying CPU clock speeds.
  • Currently, even without monetary incentive, there are still a few hosts that falsify their CPU/GPU names.
5 years ago in #gridcoin by
$0.00
    3 votes
    Reply 1
    Sort:  
  • Trending
    • [-]
     5 years ago  

    All good points. In order:

    1. The newest BOINC credit system is more sophisticated, but still has other problems. Regardless, this is a problem that affects the current distribution mechanism as well. Fundamentally, this is something that BOINC needs to take care of, and is beyond anything that can be done Gridcoin-side. It's not exactly clear how this problem would affect rewards under the current proposal, similar to point 2 of "Impact of the Changes".
    2. That's a problem. I wasn't aware that the coprocs was that bad, I'll have to think about that more. When the process is a bit further along it would be great to have your insight.
    3. Those inherent differences manifest themselves in higher/lower granted credit per unit time. It might not be reflected in M and thus the normalization, which is definitely sub-optimal (and means that the normalization is further away from the "ideal"), but users with better configurations will still receive more GRC.
    4. With enough data and a good selection rule as discussed at the end of the "How is M built?" section, this problem should be mitigated.