Current Month Earnings in Node V1.67.1

Hello

3 of my nodes got updated to V1.67.1 this night and the numbers for Current Month Earnings in the dashboard dropped up to -58% from yesterdays values

                                                         2022-11-16  2022-11-17
                                                         06:30 UTC   06:30 UTC
Node 12o3nQ2feqEMg8WHWYGVCnUhCCUbSHJFcFbFTNqaKnesehSvpi1 $ 4.00      $ 1.68     -58%
Node 1fw82jTZ8wRWZBrP9ZDU6tFuiABeNQsG2uV4izd9uLychUdrQr  $ 0.82      $ 0.53     -35%
Node 1kZUXeZpGnTNxkSeeiv8P8kgNkvLCb9nJdzH1a8e4u5vXUyvaE  $ 0.73      $ 0.45     -38%

Any ideas why?

P.S. The script from @BrightSilence seems to show the correct numbers.

1 Like

@littleskunk and @clement: This seems to be connected to the change in disk space usage. It displays wrong values for my first node to update.


On the right you can see the correct value of 2.74TB used, but the graph shows less than 2TB per day.



Payout info matches except for disk average month… which shows a whole different wrong number compared to the other dashboard screenshot… not sure where that’s coming from.

2 Likes

This discrepancy seems to predate the update. This is on a node which hasn’t been updated yet.


The most recent day shows 111.4TB*h, which is 4.6TB*d, significantly lower than the 5.29TB used. Seems like some of my nodes are underpaid for storage usage… any idea how that is possible?

I’m seeing the same problem on my 1.67.1 node as well.
I was wondering why my earning dropped on grafana all of the sudden.

Thanks @BrightSilence, I just want to be sure of what is happening before I comment or do anything about this.
My quick guess is that the payout is probably still calculating using the tb*h… So it’s probably getting the total disk space used this month and dividing by (24*30) instead of just 30:

29.89TB*d / 30 = 996.33GBm
29.89TB*d / (24 * 30) = 41.51GBm (which reflects the wrong value on the payout info)

1 Like

Looks like that’s exactly what happens: storj/service.go at 961e841bd761e738b5e4a25693881174c0dd3ffb · storj/storj · GitHub.

Submitted a quick PR here https://review.dev.storj.io/c/storj/storj/+/8912 that fixes this.

5 Likes

Nice, yeah, that seems right.

Some friendly advise for the future. Don’t use an existing variable and give it a different meaning. This wouldn’t have happened if you had simply calculated a B*d variable based on the existing one in a new variable.

LGTM

The other issue I outlined with some (many) of my nodes showing highly different numbers for TB*d compared to total stored is unrelated. I’ll create a different post around that.

Is there going to be an update that will fix this before next payment run?

It’s a visual bug, it doesn’t affect payouts.
The fix would be likely in the next release.

1 Like

It may not affect payouts, but for everyone graphing our nodes outputs, we now have an undetermined amount of time where those graphs will have incorrect values. While its only annoying, its very annoying.

3 Likes

My node on testnet is already running 1.67.3, which seems to have fixed this issue. 1.67.1 is currently being rolled out to production nodes. It’s possible 1.67.3 will make it to production nodes as well. In that case it might be sooner than the time between normal update releases. It just depends on whether Storj deems it important enough to publish a bugfix release for this. Perhaps @clement can enlighten us. But keep in mind it’s the weekend now, so I don’t expect anything (release or response) until monday at the earliest.

1 Like

Hello,

I have just found that my node’s estimated payout has dropped significantly after checking the dashboard today and after checking things out I realized my Disk Average Month has dropped incredibly low, from 60+tb/day to just 3-4tb/day, which resulted in the decrease of the payout. I have checked the data disk, the node and the logs, and is unable to find anything that indicate any problem.

Running docker logs storagenode 2>&1 | grep -E “GET_AUDIT|GET_REPAIR” | grep failed returns nothing, which I assume there is no problem with audit.

However, I do notice that there are yellow exclamation marks on all satellites, which might indicate something is wrong, but i couldn’t figure out exactly what is.

Attached is the screenshot of my node dashboard.

Your kind assistance please.

It is a re-used variable bug.

I think multiply by 24 to get the actual number

Thanks for the reply,

Is there anything I can do on my end?

Will it affect my actual earning? Or the value that is displayed on the dashboard is purely for display and is different from the actual value that will be used to calculate my earnings?

Thank you.

EDIT: Thanks for merging the post. I now understand what’s going on.

No, this does not affect your actual earnings. The issue has been fixed, and the fix will be part of the next release.

4 Likes

V1.67.3 has made it to one node, so it’s rolling out on the public network.

3 posts were merged into an existing topic: QUIC Misconfigured in v1.67.1

Yep, I can confirm it’s rolling out on one of my nodes as well. The same one that got the v1.67.1 update first. While some of my nodes still run v1.66.1. My guess is they restarted the rollout with the same seed, so nodes with v1.67.1 get fixed before nodes still on v1.66.1 get updated. Smart choice I’d say.

I have 2 that have gone from 1.67.1 to 1.67.3. Thanks guys!!!

1 Like

Took only 5 days from report to a fix rolling out. That’s excellent! Thanks @clement and others who worked on this!

6 Likes