comparison thread

It wasn’t an assumption, but rather speculation. Enthusiasts tend to have enthusiast hardware. Doesn’t seem so far fetched to me. And it seems that the post right after yours confirmed that it’s not a universal thing to have 99+%.

1 Like

Ok clear - yeah I get that, even though I would say there are enough raspberry 3 owners (now maybe 4) who just keep it running with an additional disk … Just thinking as my feeling was overall we have more ‘geeks’ in here running a node which could fit that image.
Nevertheless so far it looks pretty good in terms of upload. Once my docker updates I hope it’ll look similar. In my case ‘unfortunately’ I also changed my connection to a better one (hence old successrate improved from 25% to 40% already). Would have been a great test to see how my bad connection plays out here but this one is gone in a week (had both in parallel for a whlie) :slight_smile:

not to shabby
only 1hr of log…

========== AUDIT ==============
Critically failed:     0
Critical Fail Rate:    0.000%
Recoverable failed:    0
Recoverable Fail Rate: 0.000%
Successful:            75
Success Rate:          100.000%
========== DOWNLOAD ===========
Failed:                0
Fail Rate:             0.000%
Canceled:              4
Cancel Rate:           0.365%
Successful:            1091
Success Rate:          99.635%
========== UPLOAD =============
Rejected:              0
Acceptance Rate:       100.000%
---------- accepted -----------
Failed:                0
Fail Rate:             0.000%
Canceled:              3
Cancel Rate:           0.275%
Successful:            1086
Success Rate:          99.724%
========== REPAIR DOWNLOAD ====
Failed:                0
Fail Rate:             0.000%
Canceled:              0
Cancel Rate:           0.000%
Successful:            384
Success Rate:          100.000%
========== REPAIR UPLOAD ======
Failed:                0
Fail Rate:             0.000%
Canceled:              0
Cancel Rate:           0.000%
Successful:            682
Success Rate:          100.000%
========== DELETE =============
Failed:                0
Fail Rate:             0.000%
Successful:            448
Success Rate:          100.000%
1 Like

Yep, just to confirm, both my nodes are RPi 4’s with USB 3.0 connected 5400rpm HDDs (WD Elements). Although, last week I did get a new ISP with 1Gbit fiber up/down, so that might be one reason my successrate numbers pretty high on this new version. Back when I was on V1.6.4, after the ISP upgrade, my successrates were closer to ~10-14% for uploads…with this new version, I’m still rocking >99% upload successrate on both nodes after 8-12 hours.

Node 1:

Node 2:

1 Like

When I type docker name in the script i get this error :
./ 7: ./ Syntax error: newline unexpected

Also I can’t find the ( storagenode.log ) in the node storage folder, I hope someone can guide me.

I am using KVM remote storage server from some host with ubuntu 18 OS

the script should per default grab the logs from the docker container and process it…

this will however not work, if you have a redirect on your docker storagenode logs to an external location.

if you do have this, then you can add the location of the log you want to process with

./ /your/log/location/storagenodewhatever.log

Here you can find the script + additional information

and if you cannot make it work, i’m sure @BrightSilence will want to debug it with you.

my money would be on that it’s a matter of the right location…

link to log redirection, if you done this then you will need to define the log output location when running

1 Like

Your link had a new line in it.

@msallak1 you shouldn’t edit the script at all. Copying the script might not be a good idea either as sometimes people copy some html mess with it.

Just do


Then call the script with:

  • Default container name (storagenode)
  • Different container name
./ containername
  • Logs redirected to a file
./ /path/to/node.log

Raspi 4 8Gb running 64bit Raspbian and Storj 1.9.5 on an external USB 3.0 disk (WD MyBook):

1 Like

Thank you both for explaining. I re-downloaded it with your command, I also should have just went with default because I thought I had to type the path.

This is the result from new node about 4-5 days old

1 Like

Before you can run the script you need to make it executable:

chmod +x


Still waiting for my docker to be updated…


then just manually update it…

just make sure you got your full docker run command,

docker shutdown storagenode
docker rm storagenode
docker pull storjlabs/storagenode:latest
docker run… very long and complicated command i usually just copy paste…even tho i should have put it in a bash script

but yeah really it’s a 2min deal… if that…

Yeah sure I know how that works but we’ve also had multiple discussion here in the forum about not forcing to update / or keep watchtower to ensure ‘how it should be’…
I’m just whining here that’s all :D:D


why does it matter if you force an update… so long as you know it’s good…
ofc i’m not aware if doing a manual update can confuse watchtower… since i only manual update

well you better strap in… it might be days until it comes around to updating your SN :smiley:

the real test of the network will be the day something like 60% of the states blackout… or when the internet breaks or is otherwise impaired across like say the atlantic…

some major shift, that might take 30% of the network offline for hours if not days…
that will be the first true test of if this really works.

i think updating will be hard pressed to make that effect… but it most certainly could… even if kinda tricky to pull off

Yeah I’ll sit it out :slight_smile: Wasn’t it roughly within a week after the first docker update starts? I remember reading something about it but forgot it… Well. #waiting :slight_smile:

version is launched for windows, then it takes about a week before it comes to docker and then maybe a few days to update everything… ofc maybe a bit more… but the further towards the end it gets the less likely it is that, you will be the one left ofc…

hitting 10% is not all that easy consistently :smiley:

Well this is interesting. I thought 1000 uploads would be a decent sample size, but I ran the script again after 76,000 uploads and my success rate went from 91.2 percent to 98.1 percent. I didn’t change anything on my node. Perhaps it has something to do with time of day or distance to the customers that were active at the time of measurement.


there may be other factors that will play a role…
such a server or hdd’s activity, storage node activity, internet activity…
and then depending on what type of setup you have… then you might add , user activity, network activity…

then you might also have to take into account the storj network conditions… like say if nodes near you or not are performing up to standard… then you might also have some boot time where your system doesn’t run as smoothly, or just after you restarted the storagenode it will perform a lot of processes that will strain the computer and thus affect your successrate % over the short term… ofc long term it sort of drowns out… but it might be why you aren’t seeing higher than 98% but 98% is basically perfect…

i so want the last bit of DL and upload… would be awesome to get it to 99.99% in both just for kicks…

yeah, I forgot about the full node file scan that happens on node restart.

I was enjoying the sun the last two days and didn’t check, updated almost 40 hours ago … just moved old logs aside and will collect and share tomorrow :slight_smile: