First observations of my RAC prediction experiment
As some of you know I'm currently experimenting to predict BOINC RAC for certain projects. Here are my first observations. Note that I'm still tinkering and this is by no means a conclusion yet.
The math used to calculate RAC can be found in the BOINC sourcecode. It is not that hard and I'll explain it in another story once I get further with my tinkering. My current experiment uses data of a machine that is running VGTU with 3 cores 24/7.
Observation 1
Depending on the task at hand RAC can take quite some time to build up. This is a graph of one of the predictions. The value is not accurate yet. But the slope and timeframe are. In this case RAC will be rising for about a half year.
Observation 2
RAC seems to be based on reporting time and points earned. Points earned might differ from project to project and from application to application (more on that later, I first need to get this right). The important part here seems to be that this is not the amount of time the host needs to complete the task, but the timestamps of when the host reports the results. Using the CPU time I get quite close but not exactly the same. I didn't expect this.
First column is reporting time, second but last column is CPU time. As you can see two tasks are reported with no time difference. Because part of the RAC calculation is exponential and there are exceptions for 0 difference time this has influence.
Observation 3
Sometimes the reporting time is not sequential. Entry two and three should be swapped. This also has influence on the RAC.
Intermediate conlusion
My first idea was to take the calculation time as a base. After all, average reporting time and average calculation time should be the same. On average this should probably work. Because of the exceptions shown however I think this won't work. The difficulty I'm facing now is to simulate I need enough data at the right moment. RAC on the project website is calculated when the page is loaded and can't be viewed over time. There is no coupling of the RAC to the results. I currently keep a close eye on the page and try to write down the RAC as much as possible to get a good simulation base. I'll keep you all updated.
I've set up my boinc and gridcoin account on 30th August or so and I'm looking for the same answers ;)
ad. Observation 1
I guess y axis is RAC, but what is x? No of work units or hours or days?
ad. Observation 2
What I understand, credit points are given after WO has been confirmed, not just reported. (Thus there exist task pending list.)
My very rough estimation is (note 0.5 = 50%):
i.e. you get to 50% of your max RAC after a week and almost 100% after 2 months. I will double check these numbers later, so take them with a pinch of salt :)
x in that chart is days since start
AFAIK points are indeed calculated when reported but rewarded when the WU has been confirmed. That's why I chose VGTU, a reported task seems to be confirmed right away. Maybe they don't need to check, I didn't look into it. You have a valid point here. But I like to start with as little variables as possible. Stay tuned, I'm making progress and will report here for sure.
jefpata, I'm wondering the reason why you are trying to predict RAC?
Are you thinking of publishing the predictive results?
Courtesy of @joshoeah
Maybe I should have mentioned that in the article. Was a bit too enthousiastic :-s Basically it is the first step in trying/estimating PoW reward. You might think profit is my first goal but it is not. There are always lots of talks about which project to choose. Some don't care about profit. Others want to maximise. Some don't dare changing to something they like better. Lots of reasons. The current answer almost always is 'it depends'. And it does. But estimating the RAC and combine it with mag can give an indication. Gathering more data on how it works exactly, what the strong points and weaknesses are might benefit gridcoin. The system is based around but most of us admit it is not perfect. Every bit of understanding might help in the future.
jefpatat, if you are going to collate results into some form of guide offering information to our community I'm with you all the way.
If I can help by giving you stats from my crunching the offer is open.
I would like to see some objective statistics gathered which will be of benefit to everyone, after all we are a transparent community and there are no jealously guarded secrets.
Contact me on slack if you wish my help and we'll have a discussion.
Courtesy of @joshoeah
Exactly. That's the spirit. I'm actually thinking of going a step further and make a tool that estimates the future RAC (and GRC) based on the past. There are lots of constraints to do so, but under circumstances it should be possible to some extent.
In the meantime I got lucky and got data for both observation 2 and 3. My calculations work. It's not easy however to figure out how to merge these in the estimation. At least now I can try and simulate.
Once I get further I will request for more data. I will possibly be looking for the two extremes. Hosts that just start up a project and hosts that have reached a stable RAC.
Stable RAC? Well if you could call any RAC stable I could offer you that . Been crunching the same projects for a while.
Courtesy of @joshoeah
Which project and how long?
RAC is based on two factors:
-Credits: Every project decides the amount of credits that provides for completing every task. Most projects just give a credit reward proportional to FLOPS required estimation. Projects that has more than one app can give additional credits to one or more apps.
-Time: The average number of Credits per day granted recently. This average decreases by a factor of two every week.
https://boinc.berkeley.edu/wiki/Computation_credit
That is what the explanation states. And I believe it was correct for a previous version. The math in the code is different.
https://web.archive.org/web/20080311233928/http://www.boinc-wiki.info:80/Recent_Average_Credit#Updating_the_RAC is the best source I know of. Still... Code is the best source.
Actually doing the math the formula does the same I said, probably I have not explained myself properly. RAC value is a weighted mean, today credits has the maximum weight, credits obtained 31 August has 1/2 weight than today, credits obtained 24 August has 1/4 weight than today and so on.
No, that is not completely correct. The decay works as you explain it (I think, I have not yet looked at it in detail) But the build up is explained like that but doesn't function like that. It is explained as a low pass filter. Older values have less weight. The important difference is the point of calculation. It is like a low pass filter with 'random' sampling points. The calculation happens every time when a new result is available. There is nothing that calculates the RAC every day so there is no way to calculate it as you explain it. Reread the article observation 2 and 3.
To clarify. Suppose you have one task that takes 13 hours. Today you will have one result, tomorrow you will have two, the next day one, ... The way you explain it will yield a different result than the way I explain it because you will have a different amount of calculation points.
Got it. For adjusting the results to PoW reward, your experiment should monitor the RAC in the Gridcoin Neural Network. The tables you are showing are from the project page, right?
The last time I checked neural network data seemed yo be updated once per day, but it was several month ago so I am not sure if that still works that way.
Thanks for the info. That would be important for estimating PoR.
@jefpatat got you a $4.97 @minnowbooster upgoat, nice! (Image: pixabay.com)
Want a boost? Click here to read more!
Congratulations! This post has been upvoted from the communal account, @minnowsupport, by Jef Patat from the Minnow Support Project. It's a witness project run by aggroed, ausbitbank, teamsteem, theprophet0, someguy123, neoxian, followbtcnews/crimsonclad, and netuoso. The goal is to help Steemit grow by supporting Minnows and creating a social network. Please find us in the Peace, Abundance, and Liberty Network (PALnet) Discord Channel. It's a completely public and open space to all members of the Steemit community who voluntarily choose to be there.
This post has received a 1.56 % upvote from @drotto thanks to: @banjo.