i’m seeing something similar cannot say if it was like that pre update, i don’t look at those to often, pretty sure it was all 100% a few days ago… but then again… 99,99995 is also kinda 100% …
had a bit of downtime last night, but i seriously doubt i failed an audit, most of the time i have been running with an shutdown on failed audit script… tho not 24/7 and i could check my logs… but i’m feeling lazy
checked anyways… figured it might be fun to make use of my logs for once…
./successrate.sh storagenode-2020-10-**.log
never showed it before… but yeah in the past… 4-5 months ago i may have failed an audit or two… i forget why… might have been recoverable mostly… but also had some points where the system locked up and the node was all crazy for a bit
so it’s possible it’s just visible now… would make sense
your numbers might be a bit more troubling if you duno why you get 95% audit score on some satellites…
that could be a sign of a pretty serious issue… ofc it should be visible even when rounded
i would assume an audit needs some sort of communication and if one is failed… and then it is reattempted later okay… maybe … but still that would mean i should reboot just in the middle of an audit which sure there is a decent chance of… and then i have to come back and then reboot right in the middle of the same audit…
seems unlikely… but really given i don’t really know how it works in the programming i cannot really say… but sounds unlikely… and i would expect not to be audited unless i am able to actually communicate and besides, if the satellite wants to check a piece it can just ask… they are all there every damn byte
if it did think something is broken, which i know it’s not… then i expect it to ask me again, can’t expect my operation to be 100% fault free, sometimes i need to maintain and make changes to my system…
which will cause the node to be unstable… because i don’t really shut it down
pretty sure i got this failed audit because i did a zpool remove on my slog device or l2arc without shutting down everything else first… apparently when stuff is running aside from the OS it can be difficult to remove such things from the pools that are active in use…
but i didn’t know that and tried, which stalled the entire system, the node would continue running but disk access was… bad enough that i couldn’t do a reboot command… which kinda drives home the latency
i could however open docker logs and see them live… eventually i had to pull the plug… did that a few times pretty sure i got some failed audits there… but never actually lost any data… not a byte
I think some rounding could be good but not too much. I’d rather have too many decimal places than not enough. In my case, if my scores had all been rounded to 100, it would not be apparent to me that I seem to have failed 1 or more audits and that my score is slowly increasing over time.
Attached below is an animated gif of 3 screen shots captured at random times all in about the last 24 hours. Notice the number in the lower right side changing. The number of decimal places shown seems to fluctuate which is a bit annoying. For my current scores, I think 6 decimal places would be enough for me to track my audit percent as it changes over time. My node lost about 10 pieces as I was copying node data off a failing hard drive a few months ago. I’m glad we now have decimal places so I can see what effect the lost pieces might be having on my audit score.
i like the details, but like jammerdan says maybe keep it a bit more limited…
in most cases high precision numbers are not useful for much anything else than tracking audit recovery…
so it might really just end up causing confusing for a lot of people that doesn’t need to see the number… ofc one shouldn’t round it to 100 in cases of 99.99999995% then because how would one tell it’s not 100%
but yeah not to many numbers
and just thinking out loud
oh and people really suck at rounding numbers… or i’m still half a sleep
In fact it really looks like once an audit fail, the score never ever gets back to 100%.
So IMHO, when it got back close enough to 100 (e.g. 99.999) we should consider the score to be back to perfect state, that is 100%.
I really don’t see why you would want to display 99.99999999 on the board.
If one wants the exact figure, they can use the API directly, not the board.
So yeah, agreed the number of decimal places should be limited on the board.
maybe so… and yes i fully agree such a thing should be fixed…
even if it’s a very minor detail that may result from some math that isn’t flawless…
pretty damn close xD
I’m all for keeping a close eye on things, but until the last release Storj didn’t even show it as a warning before it dropped below 75% (95% now). Sometimes too much information is just that. Too much. For the earnings calculator I chose to round it to a single decimal point. If your node has a score over 99.95% you really have nothing to worry about anymore, so it’s fine to show 100% then. I like the idea of full detail on mouse over though.