Disk Space Used This Month Graph Displayed as TBm

[SGC]

I think we can all agree this graph plot is useless and hard to read for new and old SNO’s alike.

My simple suggestion, inspired by the recent change in v1.9.5 payout from TBh to TBm

Plot the graph in TBm instead and over multiple months.

this will give the graph a smooth useful linear progression of a storagenode over time in a way which SNO and casual onlookers can easily read.

it will also correlate in line with the payout making it a standard for how SNO’s read their dashboard and payment details, essentially making TBm the KWh of Storj

[littleskunk]

I believe we talked about that topic in the changelog draft thread? That was in a private area so let me post my response here was well:

I created a bug for that a few days ago. Let me copy it.

Used Space Calculation
Let’s say a storage node is holding 1 TB of data. On the satellite side tally is responsible for accounting. Tally finds 1 TB and takes into account how frequently it is running. If it runs every hour it will write down 1 TBh. At the end of the day, we have 24 TBh. If it runs every 8 hours it will write down 3 times 8 TBh. At the end of the day still, 24TBh.

For the following example, lets assume Tally needs 23 hours to run and will write down 23 TBh. On 23 days in a row the satellite will write down 23 TBh per day but on the 24th day, the satellite will finish tally early in the morning and on the same day finish a second run. For that day tally will write down 46 TBh.

Now that we have one day with 46 TBh it is time to talk about the storage node dashboard and what it should do with these numbers.

Actual Behavior
The storage node dashboard gets the 23 TBh and the 46 TBh results from the satellite. It prints these results into a graph. Included in that print out is the assumption that the 46 TBh result is for a 24h window. That assumption is wrong and so the graph will contain a spike while the storage node was holding 1 TB all the time.

Expected Behavior
23 TBh / 23 hours = 1 TB. 46 TBh / 46 hours = 1 TB. At any time the storage node could print out an accurate graph. All it needs to do is aksing the satellite what the time window for the 23 TBh and the 46 TBh was. Tally has noted the time window. The data for an accurate graph is available.

Optional: With the time window the storage node could print out 24TBh per day. The graph would be accurate at any time. The follow-up question would be why don’t we print 1 TB instead of 24 TBh. That would make the graph better to read outside the simple 1 TB example. However, in the first place, the graph needs to be correct regardless of the unit we use for it.

@SGC any questions on that? I hope my description is clear and easy to understand?

[SGC]

not sure how i quite missed that on the first pass, but yeah eliminating the time factor or fixing the time factor is a good approach to fixing it…

i ran into a similar issue when i was exporting my docker logs… because i told it to extra the last 1 minute of every minute… and ofc it would not be perfectly accurate because of different server workloads and what not… so some log lines might get skipped or doubled in the appending exported log the command was created…

i ended up fixing that, buy simply taking 1 minute old data, instead of actual current data…
so instead of taking last 1 minute on the exact minute which touches the present and thus becomes unstable…

i took from 2 minutes ago until 1 minutes ago using whole numbers… that way i got perfect meshing of the appending in my live exporting docker logs.

not really the exact same solution here, but kinda the same problem in a sense…

i still hold that the period is to short… my node is 5 months and a bit more than half full… it would be nice to be able to see the graph for the full life time of my node and how it’s growth curve is…

i didn’t realize you had a solution for the tally issue… and just figured… if one plotted the avg graph over months and showing TBm would eliminate most of the confusion, with a solution i could come up with…

yes thanks i understand, that apperently it might already be a solved issue, which would be great…

still if nothing else the graph could use a day/week/month/year scale selection…

my node has getting what… maybe 2TB ingess in the last month… thats from 11 to 13…
so even if the instability goes away, because of the scale… the graph just becomes an almost straigh line in most cases…

PS another weird thing i don’t understand is why sometime i can see who i respond to in the forum threads and other times i cannot… but i suppose i can just start to use the @ instead…

it shows that i responded to you when i edit, but on the forum i cannot see it… but maybe it’s just some browser update i’m lacking or whatever… i suppose i should go try another browser see if that helps
might be worth a shot…