Current Month Earnings in Node V1.67.1

To the person who wrote the fix, YOU’RE THE BEST.

2 Likes

I just restarted my nodes, and the ones on 1.67.1 reverted to 1.66.1. All nodes have been fixed. THANK YOU STORJ!!!

1 Like

I also have QUIC misconfigured after the update. Restart didn’t help. The “Disk Average Month” statistics data has been reset.

[image]

this node is 3tb full but displays 74.31GBm

UPD: QUIC is ok.

why is my disk average been resetted going from 1.66.1 to 1.67.1 ?

Same here regarding restart of “Disk Average Month”. Also, QUIQ is now misconfigured (it shouldn’t…).

Hi all,

Just had a look at the dashboard of a node I run and noticed a fairly massive difference between the reporting for data used and the reporting for actual payable data for November. This is weird as the reporting for used data for October is quite similar to November but reporting (and actual payout) for payable data is totally different. How could a node that stores about 1.44TB throughout the month with nearly 100% connectivity report 54.49GBm as disk average when for last month - with an almost identical Disk Space Used This Month -graph - it was reporting 1.31TBm?

I checked out some of the late topics related to this and it seems there is both a problem that does affect payouts and also one that would not seem to. How would I determine what my case is about? Or is there something I missed here and this is quite usual?

The node is running on a baremetal Ubuntu -box which is connected by a 1GB fiber and is quite a fast one.

Any comments on this? I made a collage of screenshots taken just now which displays the issue I seem to have:

See Discrepancy between B*h reported by satellites and storage used on node (impacting node payouts)

Hello @Fazed,
Welcome to the forum!

I guess your node is on v1.67.1 and it has this bug, it’s fixed in v1.67.3

Hello @Alexey and thank you!

Yep, the node is on automatic updates and has updated to v1.67.1. I was guessing the bug might be the reason for my issue but was not quite sure as it seemed like there were other issues happening to a few commenters.

Is it fixed in v1.67.3? I had v1.67.1 and it got updated to v1.67.3 and it still displays the same value.

Ctrl + f5 doesnt help, tried.

Can you post a screenshot or a little more context of what number you think is wrong?

The Current Month Earnings on the main page is still wrong, but corrected on Payout Information page.

5 Likes

thanks for posting this - just got further node upgraded to 1.67.3 and was a bit confused as payout dropped to ~25% of the normal value.

@clement I was looking into how the graph got smoothed out. Clever approach and it seems to work well. But I noticed some flaws in the approach.

Because of the use of a LAG record, the first record (first day of the month usually) doesn’t have a previous record and always assumes the Bh are for 24 hours, even though that can be wildly off. As a result, the first day result is not reliable.

Furthermore, these derived numbers are then summed for the total, which is no longer completely accurate. I noticed this on the 2nd of the month when my earnings calculator had a much lower number for estimated payout of data stored. It was more noticeable at that point because it also assumes that data has already been stored for 2 full days, but the estimation looks at how many hours have passed and extrapolates from there. Because the hours passed were far less than 48 hours, this overestimated data stored.

Now none of these are critical differences and they smoothen out somewhat as the month progresses, but there may be some outliers. We’ve seen in the past that sometimes satellites take more than 24 hours to update the storage used. It used to be the case that a day of 0 usage would be compensated the next day, but I believe that the current approach would lead to a day of 0 and then the next day that data is available again wouldn’t compensate for that and the total would be missing that day of storage altogether.

So while this change was great for stability of the graph (and much appreciated). I don’t think it should be used for the total, especially in the payout calculation.

Furthermore, the issue with the LAG function can be resolved by adding on some more days at the start (more than 1 just in case the satellites are running behind again). Then limiting the result set to the exact dates outside that subquery.

As for my earnings calculator, since I’m only displaying the total and using that also to compare to eventual payouts, I’m sticking with just summing the records as is, because I want it to match what satellites actually pay out for.

For anyone reading along. None of this impacts payouts. These are just discussions about how the data is displayed on the node dashboard. Payout calculations happen on the satellite and are based on exact data. Not these estimations.

2 Likes

@BrightSilence thanks for the observations and greatly listing out your concerns.

Yes, I am well aware of this issue and I have a ticket on that which I’m currently working on [storagenode] Wrong payout calculation on dashboard · Issue #5355 · storj/storj · GitHub. The ticket indirectly covers all the other concerns mentioned except for the usage of LAG. Also thanks for pointing out that it is only a visual bug for other community members reading it. It does not affect the actual payout and the difference is mostly (not at all cases) insignificant.

This is true. I will open a separate ticket on this but will work on both together.

3 Likes

Thanks for the response. I guess I should have checked the issues on github before posting. I figured you were already aware of most of this. And I agree that the differences are mostly insignificant, especially when we get further into a month and the differences start to cancel each other out more.

Keep up the good work!

2 Likes

For calculating the total above the graph (and possibly for use of estimation of month total) you could divide the total Bh by the total timeframe covered by storage usage records.

SUM(at_rest_total)
/

(
	MAX(CAST(strftime('%s', interval_end_time) AS NUMERIC))
	-
	MIN(CAST(strftime('%s', LAG(interval_end_time) OVER (PARTITION BY satellite_id ORDER BY interval_end_time)) AS NUMERIC))
) / 3600

I think Bm in the payout overview should remain a simple sum of at_rest_total across all records.
This query isn’t correct as the aggregation needs to happen outside the subquery (and given how you described the issue, probably not as part of this query at all). It’s just an indication of what I meant to say.

Again, you probably are already aware of this. I’m posting my suggestion just in case.

I’ll make some adjustments to my earnings calculator as well to get a better estimate of end month totals. I hope you don’t mind me using some of your ideas in my code. :wink:

Hello, I have the same problem in v1.68.2. Its not fixed yet right ?

It’s corrected in the Payout Information page, but not Current Month Earnings on the main page, see

seems it should be fixed in the next release: [storagenode dashboard] Current Month Earnings doesn't match Gross Total on the Payout Information page for the current month · Issue #5354 · storj/storj · GitHub