‰ of stored is derived by dividing the stored total tb into egress gb…
daily egress / stored total = ‰ of stored
i went with that method because it’s nice and easy and no numbers needs to be changed/converted or whatever…
you simply plug in egress / total
and you got ‰
simple enough that one can basically do it without a calculator tho getting it really accurate a calculator helps alot…
its usually most jumpy if the test data starts and stops… the bigger the jump the test data ingress seems to do, the more crazy the graph gets… even if the ingress is like 250gb of 10tb… then the graph just goes all out pendulum… anyways they have been trying to improve it i think… but its still highly unreliable and also only updated 1once or 3 thrice a day. which i guess if why it jumps like that… it will simply carry information into the next cycle…
Just changed it to stored total
So “stored total” or “Disk Space Used” is now from “Total Disk Space - Used”?
used obviously 
else you would not get the relative ratio comparable across different nodes… because their total size would partly define the ratio…
ofc on full node it doesn’t make a difference
its all relative lol
Just trying to understand the new spreadsheet sources
haven’t checked that at all yet… but i will… been looking into methods of capturing the data instead of us having to spend time writing it all there…
would be neat if we just had a script we ran by the end of the month or daily that will capture it all and then one could just paste it into a database or the system could also do that all by itself…
the idea with the ‰ of stored, was simply to be able to compare all nodes ingress in relation to each other… without much bias…
sorry didn’t mean to insult… i just went through a few variation before i settled on using ‰ of stored…
the ‰ was for accuracy and because it worked so great when doing the math, because dividing the tb number into the gb number would give 1/1000th.
and i settled on stored because it implies the data used… not the store, storage or total concept… maybe i over think things, but i like stuff well defined like that.
when possible lol
or time for it is well spent.
meh can’t even read the google docs… its all in like russian and i cannot change it without making an account… 
google you don’t own everything yet… how about you act like it…
oo is christ
le is EL in reverse… g is 6 on its head
and it contains 6 letters…
El is the short form of elohim, but often El is just used…
brought to you by alphabet, because they can’t spell lol
Is ‘Egress’ in your calculator only ‘Usage’ or does it also include ‘Repair’?
For my first node I have 47.72 GB Usage + 11.28 GB Repair + 381 KB audit for a total Egress of 59 GB.
include repair as well since we don’t worry about payouts but rather focus on the total amount of egress
having a script would be awesome ! Unfortunately I’m not comfortable enough with coding to throw one together, might have a look later when I have some more free time.
The main point would be to get the data from the docker container.
initially when we started, we checked the ingress… and tried to compare it… but after a while it became clear that adding both regular ingress and repair ingress together gave us insanely accurate numbers… additionally all nodes from each SNO is also added… so ingress + repair ingress + same for additional nodes which gives the total daily ingress
this ingress will most often be within 1% of other nodes running smoothly , ofc minor variations do seem to factor in…
i extended this practice to the egress also… all egress/repairE of all nodes of a SNO is simply added into a daily total.
duno if this is a mistake… maybe the numbers will be more consistent without it… i might try and check up on that but i doubt it…
assumptions are dangerous things xD and what worked for ingress might not apply to egress
Maybe older nodes might get more repair egress because they have older pieces but I’m not too sure about that.
yeah that is very likely… tho it might also be kinda random… like say which data came on to the network, which nodes was closest to the customer… ofc with test data this is or might be fairly uniform… but really i’m not here to measure test data…
i mean… no point in designing for test data when it will either decrease or just remain about the same at one point… then its mainly customer data… and if one have made any specific choices to optimize for test … then its outdated
but then on the other side everything gets outdated… but i digress…
i think you are right… tho age might not be the only factor… could be 1 month old data and then a couple of big nodes close to your node crashes and burns… then you might see lots of repair…
ill try to track the egress separately next time do a summery… just to see if it matters…
however if we are writing it into a database… then my general rule of thumb is not to skimp on the information… its easy enough to add it up when its in the database… however one cannot take it apart, if only 1 data point is entered… this allows for more targeted analyzes of the data in the DB… but then again it will take up more space, and more processing … and one might never need it… but simple data such as this i doubt its a concern…
alas the more data the better…
Just added a second node on the same hard drive so that it’s vetted whenever I decide to get a second HDD. It also minimizes the held back amount so less money lost if node ends up corrupted.
Did anyone else see a sharp increase in ingress yesterday ?
My ingress shot up to 150GB from a consistent 120GB the last couple of weeks.
I checked the dashboard, I was wondering if some satellite other than europe-north started uploading but no. Ingress from all satellites decreased yesterday and europe-north increased by about 20GB.
I’ve noticed that on my node also.
Maybe they are testing what is real amount of free storage (in case people “state” too much free space)
I was expecting a drop in ingress on my big node due to adding the small one, I guess I’ll see if it’s had an impact over the next few weeks.
