I am an active Gridcoin Stats user and part of the input for this weekly project update is normally taken from this website.
Due to recurring forking issues, Gridcoin Stats still needs to resync regularly, making the information on the website less accessible and more often incorrect. Today this was the case as well unfortunately so I took the decision to temporarily obtain information from other websites and calculate the Magnitude and GRC per 1k system RAC myself using the following formulae:
As this is the first time that I’m calculating the GRC per 1k system RAC with RAC values directly, I thought it would be useful to include the table with calculation details in this article (table below).
(Source: [1] and [2])
It is good to see that most results are in-line with last week’s stats update and any differences are easy to explain (for example the major jump in GRC per 1k system RAC for Universe@home is caused by the lack of WUs). On the other hand I do hope that Gridcoin Stats will soon be my reliable source for Gridcoin information again.
And here the charts as usual for all whitelisted projects. The definitions per indicator can be found below the charts.
(Source: [1], [2] and [3])
Definitions
- Recent Average RAC = The total amount of RAC produced by all systems within the Gridcoin network.
- Team RAC vs Overall RAC % = The proportion of RAC output team Gridcoin has produced as part of the overall RAC for the project.
- GRC per 1k system RAC = The amount of GRC you will receive for a system per 1000 RAC points. Example: You have a system which is running Rosetta@home with a RAC value of 3500. According to the chart on 30-Oct, you should gain 3.5 x 0.42 GRC = 1.47 GRC per day for this system.
- USD per 1k system RAC = The amount of USD you will receive for a system per 1000 RAC points. Example: You have a system which is running NFS@Home with a RAC of 4700. According to the chart on 30-Oct, you should gain 4.7 x $0.29= $1.36 per day for this system.
Thanks for reading. Follow me for more BOINC & Gridcoin related articles.
Do you have plans to do a study around WU size / time required to compute v/s credit's per package also how much delay is present between submitting result and verification.
example with srbase its instantaneous where as primegrid takes a lot of time to give you a confirmation on validation.
Simmilarly A project might have WU of 4 hour each but i get 1000 points where as B project might have WU of 2 hour each but i get 100 points.
in such scenario;s its not maintenance but rather establishing the RAC is bigger issue.
Some stats on those lines do make sense.
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
These are indeed valid observations and it is an intersting area to explore. I already have some ideas but I first need to have the basics in place to capture the required information. It is on my list.
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit