Erroneous values for egress, TBm and estimated payout

Hi

In March, my 5.5TB old node had already made about 14$ last time I saw it. It never went under 5.5TB during the month. Oddly, it was estimating to make about 7$ by the end of the month. Today I realised why:

For some reason, I only did 3.46TBm (???). Also, I’m quite sure my egress during March was a lot more than 65.46GB.
I’ve noticed the problem still goes on. April values on the dashboard are all wrong, including estimated payout. Only the actual “Current Month Earnings” seems to make sense.
What’s going on? Do I have some corrupted DB?

I know that storj delete old data, so alsmost all the time part of you storage space was lot of garbage, and it not payd, it store it 7 days, after node start to download new data insted of deleted. then storj delete next batch of stored test data. so it looks all the time full but not working for full. Also if you have old node, it has lot of test data, storj not downloading it any more so it is possible then you have very less of egress. Now as lot of was deleted and you gete more customer data it has more usage and more egress.

No!

That is not it. The node was 6.5TB. 1 TB got deleted last month. 0.5TB were deleted from trash. 0.5 TB got stuck in the trash. Initiated already this month the node without “storage2.piece-scan-on-startup: false” in config.yaml and the other 0.5TB were deleted from trash. Never went under 5.5TB.

Today I have already uploaded 8GB (not taking into account repair egress). Yesterday I uploaded 15GB.
Current period says this:

So, the sum of 8, 15 and whatever I did saturday and sunday is 8.97 GB.
The current payout is more than 2$. The estimated payout for April is 7.35 (???).
Something is definitely wrong here…

The problem is explicit in the difference between these 2 pics:

11

@Alexey

Nobody can tell me what’s going on with my node?
Will I be paid according to “Current Month Earnings” or according to “Payout/Current Period”?

“Current Month Earnings” is always the sum of all satellites. Within the Payment Information screen you can select only a specific satellite and see the corresponding “Payout/Current Period” amount.

Just a guess in the dark, are you sure it is “All Satellites” or just a single one you are comparing?

Is your node full? Cause I saw simlar when my node was full barely any egress.

It’s “estimated”. It’s not real.

1 Like

Nice one. But no, “All satellites” is selected. Just for the heck of it, I selected each satellite and check the amounts individually to find if some are missing.
Found that I’m not able to select us1 neither europe.north… (???)

Yep. The node was full. Has been since February. Only this month, after being able to delete the 0.5TB stuck in trash, it was able to start ingress.
How did it return to normal in your case?

I ran GE on all the test sats and I got full egress again.

And before GE

Sure, but I’m good at math… the estimation is wrong. Actually, it is right according to “Gross Total”. It is wrong according to “Current Month Earnings”.
It doesn’t matter anyway. “Gross Total” should always be equal to “Current Month Earnings”. It is not.

ok. full egress is a problem right now for me. I wanted to write a post about it, but wanted to sort this problem first. Anyway, this post is not about full egress. It’s about being paid for the little egress I’m actually doing. Part of the dashboard agrees with the egress I’m doing, part of it does not.

What is GE?

Maybe thats the part which is missing. Are you able to select these satellites on the main stats screen?

And what about “Payout History”? All correct till Feb and all satellites showing?

GE is graceful exit, I learned that most of the data on storj is either hot if you still get ingress you will get more egress, But cold storage is when node is full and your no longer getting ingress so egress pretty much stops because no one is downloading the data. This has been brought up many times to storj but they want to keep all the test data and for full nodes this means less income cause the data is never downloaded again and your just getting paid for stored. And the price purposed price of what we will be getting paid will be pretty much nothing if your node is full.

Nice follow up question. You’re good at this.
No, just tried and I can not select those 2 satellites on the main screen.
Feb was all good.

No. My egress problem is not related to old data. It is related to egress success rate of 70-80%.
I solved my IO problems and was enjoying a success of 99.x% since. Suddenly, with no visible reason, it all went ape shit. But it only happened on my synology nodes (I have two at different locations). The OSX node on a third location is doing fine.
I think they put a code line in some version (1.75.2?) like this: “IF synology THEN ape_shit”.

@BrightSilence , how are your nodes doing?

@deathlessdd , if you GE, you loose the nodes, no?

PS- Anyway, I’m quite sure the success problem has nothing to do with the crazy dashboard problem. My other synology nodes are doing fine on the dashboard, but they also have a low success rate. I’m quite sure this has something to do with the node being full for more than a month… now it’s not, but the problem didn’t go away… I might just be missing 2 satellites on some parts of the dashboard statistics…

As you are missing all stats for the two satellites, restart your node (if not already done) to refresh the data.
Else is there anything database related within the log files?
You can also try to check the integrity:

1 Like

I had restarted it already 1 or 2 days ago, but did it again anyway. Nothing changed, can’t select those 2 satellites.
Nothing on the logs catches my eyes, just the many “download cancelled”, but again, I don’t think that’s related to the dashboard problems.

I have this:
2023-04-05T17:52:51.721Z ERROR bandwidth Could not rollup bandwidth usage {“Process”: “storagenode”, “error”: “bandwidthdb: database disk image is malformed”, “errorVerbose”: “bandwidthdb: database disk image is malformed\n\tstorj.io/storj/storagenode/storagenodedb.(*bandwidthDB).Rollup:324\n\tstorj.io/storj/storagenode/bandwidth.(*Service).Rollup:53\n\tstorj.io/common/sync2.(*Cycle).Run:99\n\tstorj.io/storj/storagenode/bandwidth.(*Service).Run:45\n\tstorj.io/storj/private/lifecycle.(*Group).Run.func2.1:87\n\truntime/pprof.Do:40\n\tstorj.io/storj/private/lifecycle.(*Group).Run.func2:86\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:75”}

Will check the link to fix databases once I get home. I’m already late…

My bad, just read after my comment, that you have this since last month and newest version → not long ago there had to be a restart :wink:

bandwidth.db is where all the stats are stored you are missing, so you should try to fix them. Worst case the stats are lost, because they are only stored locally. This won’t affect your payout as satellites have their own data.

2 Likes

Followed the procedure to repair bandwidth.db.
It kind of worked. I now access all the satellites and dashboard is consistent.

Some differences. This is before:

This is after:

April egress started from zero, hence the decreased payout.

March also lost the egress, but recovered a veridic TBm:

I suppose it will be good after I receive the March payout, since Feb and Jan are all OK.

Next stop, understanding why all my synology nodes (and only the synology ones!) suddenly have 70-80% egress success rate after I took care of the IO problem and was smoothly sailing at 99.X%.
But now I’ll be offline (IRL) for a few days.
Thank you all for your help.