Bandwidth utilization comparison thread

About deletion of 5% I personaly not see this 5% of data deletion, on full nodes. So no ingress and no deletses. in trashh only some MB and size not moove for some weeks. But i will make so additional research for this.

1 Like

I’m aware that these estimates are not as accurate as we would like and it’s certainly possible that different scenarios lead to different results. But I would like to reiterate again that trash has nothing to do with deletions. 5% is a slight overestimation I believe. It’s probably a little lower. But I do expect that deletes might get higher the older data gets. Many backups will eventually be deleted. Whether that is after a year or 2 years or more, the older the data gets the more likely it will be removed. This is why I slightly overestimated to account for this longer term.

Really though, I would like to have much better data for this, which is unfortunately simply not collected by the node right now.

1 Like

Nice, your node got 26GB ingress (total) and egress 37 kBs / TB
My two nodes got only 19GB… - one is vetted on all except StefanBenten, second node is still vetting (very, very slowly )

yeah the vetting will take longer when you have multiple nodes i believe…
because the audits are split between each node… just like everything else… and thus only half the audits will hit the vetting node…

going to take forever to fill at this pace tho…

1 Like

02Aug2020:
Node 1:

Node 2:

1 Like

Vetting only takes longer if you have multiple nodes in vetting. Having other already vetted nodes doesn’t impact the speed. It’s not the vetting itself that is split across nodes, but the amount of incoming data. And the more data your node holds, the faster it gets vetted. Unvetted nodes only share data with other unvetted nodes.

1 Like

Thanx,
Well, i have one unvetted node and I think I will have to scratch my first node because it got malformed database. trying to restore it but it has some duplicated indexes…

Can you tell me how big is your orders.db file? mine is now ~700MB that’s alot…
Will have to ask Storjlings if it can be recovered.

That’s usually fixable, did you post this somewhere as a separate topic, with the error included? I think we may be able to help out and fix that. At worst you would lose payment for some unsent orders (up to an hour worth).

The size of the orders.db is pretty normal. That’s not the problem. But be sure to ask for help before giving up on the node.

1 Like

Created a new topic with question how to fix it and tagged Alexey in it… have to wait now.
Tried the Alexey’s fix from one of the posts but didn’t work out as expected at the end… so not much hope now, unless it will turn out that size is just too big and that db can be recreated empty…

03Aug2020:
Node 1:

Node 2:

i guess i should start to process all the data for my full month summery

I see your node is running V1.9.5, wasn’t the “bandwidth used this month” supposed to change to include deletes or is it in a later update ?

That was just a design mockup asking for input. It’s definitely not included in 1.9.5, they’re still collecting feedback on it.

Nice thanks, where can I see the modifications they made in V1.9.5 ?
I know someone sent a link in some thread but I can’t seem to find it.

1 Like

Nice thanks a lot !!

04Aug2020:
Node 1:

Node 2: