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

I have tried searching for this answer, but to no avail. I love that suspension % is indicated, as you can see running this script on my new two week old node shows 0.1%, 3.3% and 2.4% Susp.

My question is do these scores go down to 0% over time if there are no audit problems? Any idea what the time range is such as over a 30 day period?

Yes, the way this score works is similar to the audit score that disqualifies your node. It will go down with successful audits. But it’s really hard to give you a specific time frame for that because it depends on the number of audits the node gets. Especially on a new node that number could be very low, so it might take a while. Luckily these numbers are very low and nowhere near suspension yet. So as long as they’re not going up, I wouldn’t worry about them. Your node likely ran into the locked used serials db prior to the update. But if the numbers do go up, I advise you to look for failed audits in the log. That should give you an idea of why the scores aren’t a perfect 0.

1 Like

FYI - in the last 16 hours my current suspension rates are: 0.1%, 2.4% and 1.5% Susp.

So the numbers are trending in the right direction.

1 Like

Earnings calculator is really nice. Is it possible to include information of disk space used by each satellite.

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.

3 Likes

@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.

4 Likes

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?

image

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.

5 Likes

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.