Earnings calculator (Update 2020-07-02: v9.3.0 - Now with score used for suspension and warning status if your node needs attention!)

I would like to ask to make it consistent with dashboard. At the moment script shows 0.0% and dashboard 100%, it’s confusing.

The problem with making it consistent with the dashboard is that the dashboard measures successful audits where 100% is best, while the suspension and DQ percentages are tracking how close you are to being suspended or DQ’d on a satellite. At least that’s how I see it. They’re two separate metrics so there’s not really a way to reliably make them consistent other than breaking the whole purpose for the numbers to exist in the first place. That’s just my opinion though.


@vedalken254 mostly explained it. These scores don’t require SNOs to know specific threshold and also make the distinction of names much more clear. Audit score and unknown audit score are pretty meaningless to SNOs. But getting DQ’ed or suspended at 100% is instantly clear. I’d love to stick with the same numbers but couldn’t really make it clear in the limited amount of space I had. So I went in a different direction to make it as easy as possible to understand.


Why not change the dashboard? :smiley: DQ at 60% makes everything below irrelevant anyway. And there’s no suspension metric.

Ultimately they are just different metrics, dashboard shows audit value, earnings.py shows DQ and suspension “progress”.
For me that’s not confusing. It’s like having a uptime metric and a downtime metric. As long as it’s labeled clearly, it should be fine imho and not too confusing.

(guess I just repeated what vedalken256 explained lol, should go to bed…)

Can you suggest a labeling for dashboard?
By the way, it shows an audit score, not the audit checks, but still in percents

Honestly, I could imagine just changing it to “Node health” with 3 categories: uptime, audit score, suspension score. Uptime is easy to understand and 0-100% makes sense. For Audit score the number is basically irrelevant, it could still stay a number in the API but on the dashboard it could just be replaced by an arrow to indicate if the audit score is rising or falling. Same for the suspension score (although the name might be misleading because a high suspension score sounds like a bad thing…).

That was just a quick idea, I’m still not sure what I think would be best because there’s already lots of confusion about suspension and dq and both those modes get triggered from audits but from different kinds of audit errors, making the “audit score” pretty strange and confusing anyway, additionally the threshold of 60% audit score is just a number that doesn’t mean anything to any SNO so could just be ommitted or changed to a range from 0-100% so it has a real meaning to the average SNO but it would still not say much because it’s actually just a DQ score while the suspension score is not shown.

This is just a very quick mock up, but perhaps something like this?


I’m sure your designers could do a better job. Since suspension and disqualification also apply to the future uptime measurement system, these bars could represent how close you are to either in a similar panel for uptime as well. They could also be represented as a timeline there.


Thanks @BrightSilence, I was thinking about something like that. Those bars are a nice visualization.

1 Like

@BrightSilence, quick question, more just out of curiosity.

For the “Estimated total by end of month” calculation, I assume this part of the script is simply calculating the average per a time (I think hour based on what I understand in the script) and then extrapolating out for the entire month? So simple example would be if you ran the script at the exact moment of halfway through the month, then your total value would be “X” and your estimated total by end of month would be “2X”?

There’s not any special predictive or assumptions built in, right?

Correct. Predictive modeling wouldn’t really make sense in this case anyway as previous traffic patterns can’t predict future traffic patterns. So it just uses average values over the course of the month so far and shows what the entire month would be worth if that average remains the same.

@BrightSilence, Can you run this script for Dec 2019 and again Jan 2020.
Does the withheld amount increase for you against steffan b satelline in Jan 2020? If yes, what about Feb 2020?

It seems the script doesn’t increase the withheld amount for steffan b satellite after Jan 2020 for me. However the dashboard showed a continuous increase from Jan, Feb, Mar, Apr, and started slowing down in May and June was almost quiet traffic.

However the script doesn’t show any increase in withheld amount for stefan b satellite after Jan 2020, it’s always the same until GE was completed in mid June. Something seems fishy…

For my node December was the last month payout was held back for that satellite. So that would be correct. How old is your node?

Can you show screenshots of the issue you’re seeing? I’m not really following what your issue is.

Does your node Dashboard (GUI) show the same held amount as what’s returned in the earning script?

The dashboard doesn’t show the returned amount at all. But the total remaining held amount matches what the script says.

1 Like

Strangely the dashboard for stefan b held amount kept increasing after Jan 2020 (0% held amount) based on the script. But the dashboard kept going up in $ amount for every month until I GE.

Now that Payout’s have been completed for June period I am trying to reconcile for June payout and the GE and what I saw in Dashboard at the time of GE for stefan b wasn’t what I see now in July due to dashboard now showing -0 for all months. I should have taken screenshots of the dashboard in June prior to GE.

I am also seeing variance in dashboard (for all satellite) earnings vs the script earnings total in USD. They don’t match precisely.

I’m still not entirely sure where you saw the difference. But I stand behind the numbers the earnings script shows. Your node probably started in March 2019 and simply didn’t have any held back after December anymore. There are only held back amounts for the first 9 months.

The differences you see in calculation of the earnings calculator and the payouts for months you find on the dashboard are because the earnings calculator uses the nodes own bookkeeping to calculate what it should have been paid, rather then using the payout information reported back by the satellite. this is the reason of existence of this script. It’s there to double check the payout calculation done by the satellite. They don’t always match entirely, but they should at least be very close. If not, it’s worth doing some investigating.

Oh I don’t doubt the script, I suspect a bug in Dashboard (GUI) where the withheld amount kept increasing for my node for stefan b satellite that was on 0% held amount. Due to this increase every month it reach approx $178 USD in June so I decided to complete GE as the sum was to large to ignore.

After the GE was successfully completed the dashboard now shows -0 for all months for stefan b satellite and I cannot provide proof where dashboard (GUI) was showing the $178 value in June which is a large difference in the earnings script for June compare.

Held amount -0 for all previous months for stefan b…

GE successfully completed, and payout close to earnings script but not exact.

Yes, this is what I am referring in my second point moving forward for all other satellites still active, I am seeing small variances between dashboard earnings and script total earnings. Here are a few examples:

It all looks correct now at least. I know there was some issue with bad data on the dashboard that has later been corrected, but I didn’t think that involved held amount as well. Either way, I think everything seems to be correct now.

Though that June dashboard report sure looks weird if the return isn’t displayed, but is included in the total. I believe that is being added soon though. In the mean time the earnings script can clarify what’s going on.

Well, after GE the data shows -0, but my mistake was not taking a screenshot or two beforehand as proof. In any case, it’s too late now…

All I can do moving forward is review the months where variance is large ie May 2020.

Also the token’s received don’t reflect the exact $ value in USD either, even if you use etherscan “show value at time of transaction”, it’s below what should have been paid. This is now another matter to address as well :frowning:

Looks like i’ll be going over a few months manually to cross check payment (script) vs dashboard earnings vs actual payment received in storj.

  • Thanks for the script :+1:

Check December and earlier. I’m pretty sure you’ll still see the held amounts there.

Unfortunately that feature is far from accurate. There can be a long time between the transaction and the snapshot of the exchange rate they use for that. I recommend doing it the other way around. Calculate the exchange rate that would have been used for the transaction based on payout on the dashboard and tokens received and judge whether that’s reasonable for that day.