New SNO expectations

[BrightSilence]

That’s awesome, thanks for the extensive feedback. I’m actually fairly happy with how close the results are. And even better, I updated the numbers a view days ago and they are actually even closer if you look at the latest version.

Let’s go through some differences.

@o1eal

far lower “Repair” egress (285 MB vs 1500 MB)

This has the biggest difference and there is a reason for it. Young nodes don’t really have pieces for segments that need repair yet. I don’t currently correct for that and I’m actually a little surprised to see you saw this amount of repair even. It regularly takes 2 to 3 months before repair starts to take off. Since it never really accounted for much of the income I never corrected for that, but I might just add something to take that into account. Once the node has a little more data, the repair numbers start to fit better.

@o1eal

I accumulated more data than expected (120 GB vs 100 GB)

After corrections I made a few days ago, this prediction has shifted to EXACTLY 0.12TB. So it seems my corrections were spot on, thanks for confirming!

You didn’t mention this, but there is a slight overestimation on average storage over the month. This has to do with the non-linearity of receiving data. I don’t really correct for that, but after the first 2 months that difference kind of disappears anyway. So no need.
There is also an underestimation of egress. This is caused by the fact that recently uploaded data is more likely to be downloaded and in the first few months all data is recently uploaded. This also corrects over time and these 2 deviances seem to compensate for each other anyway, so no harm there.

@o1eal

One tiny bit of feedback. I found the spreadsheet more informative when I multiplied columns H and J by 1000, and divided columns I and K by 1000 (effectively, expressing “egress” and “repair” in terms of gigabytes rather than terabytes).

I get your point, but I prefer to leave it as is for 2 reasons.

• All official communication talks about compensation per TB, so these numbers directly relate to how you’re compensated
• Displaying GB would add an order of significance to the numbers that suggests an accuracy the predictions really can’t match

@o1eal

One other oddity: In the last day or two of May, the “estimated earnings” field dropped below the net total! It was 5c, while the net total was 7. Prior to that, it was always equal or greater than the net total. No biggie, but idly curious if that’s some kind of known bug.

It is… in fact, I posted this detailed report on github 3 months ago pointing it out and suggesting a very specific solution. Estimated earnings inaccurate due to use of full days only · Issue #4056 · storj/storj · GitHub

I noticed the issue at the time because it deviated from the prediction I make in my earnings calculator ( Earnings calculator (Update 2023-12-05: v13.1.0 - Now with support for different payouts per satellite - Detailed earnings info and health status of your node, including vetting progress) ) and I wanted to know what I did wrong. Turns out Storj Labs did it wrong. It’s a relatively small deviation at most times, but it can lead to predicting double the income in early days of the month near the end of the UTC day and indeed the effect you were seeing. Give my calculator a try if you’re interested. It should show a more consistent prediction as well as a lot of additional numbers not shown on the dashboard. (Also information around vetting progress, node status, payout history directly compared to your nodes own stats for previous months etc. Check out the topic for more.)