Hardware : Some random server i had laying around, 60gb ram, 2TB nvme SSD Bandwidth : 1Gbit synchronous Location : Germany Version : 1.3.3 Uptime : 335h
Your results is right around what most good nodes see atm. Upload success rate might seem low, but the majority of those canceled uploads are actually finishing just fine. The cancellation happens right when the node is finishing up the transfer and the piece is still stored, and later can be downloaded as well. You’re paid for these pieces like normally, so despite the weird log line, the pieces actually arrived on your node just fine.
These were some leftover nvme, so i don’t care much anyway haha
Also does it make a difference to have a small node and expand it as soon as it gets filled up, or should i just make it huge from the start? Right now i have 500gb of storage reserved to Storj, but as i said i could ramp it up to 2TB.
i take it that this is the new normal had a successrate of atleast 80% before i updated, also did a few bios changes, which now in hindsight was at a bit of an inopportune time.
hmmm weird, just tried the new successrate.sh script… but still get the same result…
seems like my bios battery in the server is dead and because i had pulled the plug on it recently it dropped its bios settings and my quick reconfiguration had missed a lot of apparently very important settings.
so better get those documented when i get them fine tuned again lol i WAS AT 85% now i’m up at 65%
always document every thing… atleast it’s not like a year since i did the bios tuning… lol i was barely even done…
tho one thing that i do kinda wonder… is if the successrates doesn’t match the actual successrates because the logs are wrong…
then how do i know that it actually changes my successrates, as it wouldn’t show up in my bandwidth… in fact lower successrates may raise my bandwidth usage with worse node performance…
so i’m just wondering if i’m actually tuning or just [censored] …
hope you’re all doing well in these times of pandemic.
I wanted to ask something about the success rate - since the upgrade to 1.4.2 and then 1.5.2 my node is receiving very small amount of data (I don’t have screenshot for May), i.e. before 1.4.2 I was getting dozens of GB of egress per day, but now I’m only getting around 100 MB/day.
You can check the stats at http://giosal.hopto.org:14002
yeah activity level is basically flat lining at the moment, test data has been stopped for a week and before that it ran for 4 days before it was shut down again because of issues.
it’s to be expected… my successrates dropped severely when upgrading from 1.3.3 to 1.5.2 and i haven’t been able to restore it… to the 80% i where at… for today i think i’m at 63%
13% sounds low tho, but you also cannot trust the successrate number because the logs rapport them incorrectly at the moment…
so yeah you won’t know if its really that bad before that is fixed…
it won’t hurt your node to let it run like it is… i would wait until you can get some actual correct data to adjust your node from.
they will find and fix the incorrect logging issue some time… hopefully soon.
else you can use the current numbers as a benchmark and see what helps it…
tho going through bios settings, and other performance related stuff can take a long time…
the workload is very similar to database worksloads and maybe firewalls… so that can be used as a reference when looking for optimization gains…
Bios is a good place to look… else disk latency, maybe ram or cpu related stuff… but doesn’t really require much computation, but higher frequency might matter…
my server only has 2.1ghz so not going to win any point there … but that managed 80-85% until recently… and i think it was just because i lost my bios configurations that i dropped to 55% or whatever the lowest i hit was…
cancelled uploads are reported wrong in logs… so i would say look at the web dashboard and check that the node is still growing… if so then i wouldn’t worry about it…
at some point the Storjlings will find the error in the programming and fix the log issue.
it’s not the script… it’s some how related to how quickly the computer internally responds to stuff i think… like say your node is getting an upload, then the upload completes… and the system has some processes that needs to be done with that and then before it’s done the cancelled command from the satellites come in… and it gets immediately recorded in the logs…
while the upload is still being proof read or whatever.
its most likely something like that…because it seems to vary alot from computer to computer.
however the system works fine… the satellites will still get the file from your node and your node gets paid and all that… it just logs it wrong…
For what it’s worth I did some manual lookups for pieces that were shown as a canceled upload. 10 out of 10 for the ones I checked were on my storage afterwards. Meaning the transfer did finish. Unfortunately I think that means these numbers are currently virtually useless.
You can follow this bug here: https://github.com/storj/storj/issues/3879
yeah i still haven’t managed to figure out why i dropped 20% in successrates, seems related to bios settings or maybe workload atm because i’m pretty sure i’m back at my previous bios settings.
where i was able to get 80-85%, this morning i was at 61%.
barely even feel like trying to fix it since they are most likely all there anyways…
is a bit odd that it has been consistent for the first 3 months at 75%+ and now is barely able to go past 60
maybe it’s time to write our own way to check a log against the actual files and get a true successrate…
