Abysmal Upload Success Rate

How do I find out why my upload success rate is so low?

Audit Success Rate: 100.000%
Download Success Rate: 100.000%
Upload Success Rate: 11.943%
Repair Download Success Rate: 100.000%
Repair Upload Success Rate: 97.778%

It’s not lower than for many others. You’re basically “fine” for now.

1 Like

Most likely your upload simply finished too late, the recipient got all the necessary pieces to re-assemble their data from other storage nodes and thus cancelled yours.

I’m on a >10g uplink and my success rate is roughly 35% right now.

hmm, i have windows gui, connection 300/300 success rate 70% do you have docker or GUI?

How is your storage connected to your PC?

This is a docker setup.

Internal to the server via SAS.

what is your initial configuration string?
what show
docker stats
also docker ps - there shold be only storagenode and 1 whatchtower

docker stats
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
541bdfd7697b storagenode 1.36% 169.5MiB / 23.59GiB 0.70% 67.3GB / 32.2GB 381MB / 0B 58

Not using watchtower

docker run
-d --name=‘storagenode’
–net=‘bridge’
-e TZ=“America/Los_Angeles”
-e HOST_OS=“Unraid”
-e ‘WALLET’=’’
-e ‘EMAIL’=’’
-e ‘ADDRESS’=’.com:28967’
-e ‘BANDWIDTH’=‘6TB’
-e ‘STORAGE’=‘2TB’
-p ‘28967:28967/tcp’
-p ‘28967:28967/udp’
-p ‘14002:14002/tcp’
-p ‘7777:7777/tcp’
-v ‘/mnt/user/appdata/StorjNode-V3/identity/’:’/app/identity’:‘rw’
-v ‘/mnt/user/appdata/StorjNode-V3/share/’:’/app/config’:‘rw’
‘storjlabs/storagenode:alpha’

It is beta today,
and why you need UDP? it only on TCP working
haw fast is your network speed?

Not sure how alpha got in there, I didn’t make that change. Should that be removed or changed to beta?

My internet is 300Mb down, 50Mb up.

very similar to myne connection, but i had this success rates on raspberry like yours, but you use SAS it mach faster.

I know that unraid has it’s own way to create these docker commands, but your REALLY shouldn’t use -v mounts, especially on unraid. It has the tendency to start containers before the storage is available and with -v mounts docker will just ignore that and store data inside the container instead. Meanwhile you’ll be failing audits and basically writing new data into a black hole. If you then fix that situation, you would have lost all the new data received during the issue. This is a great way to get disqualified really quickly. You also don’t need to forward UDP. And you should be using the beta tag as mentioned.

Back to the topic at hand. Uploads are closed more aggressively by the uplink now. Context cancelled failures don’t always mean that the transfer didn’t complete. This has been verified by comparing nodes with big differences in upload success rates, but almost no difference in actual data transferred. I wouldn’t worry about these success rates too much.

3 Likes

I’ll take a look at converting -v to --mount but as you said, currently -v is the unraid way. I have the container set to start 60 seconds after the docker engine starts for a buffer.

I just changed to the beta tag and it’s up and running.

Thanks, the low % was shocking, but if that’s the ~norm now, then I’ll just monitor and let it be.

I’m getting higher success rate:
Uptime 250h

========== UPLOAD ============
Successful:           177703
Failed:               72290
Rejected:             0
Acceptance Rate:      100.000%
Success Rate:         71.083%

Maybe the aggressive connection closing does not happen on my node…

It does happen more on some nodes than others. I’m seeing similar numbers to yours as well. Rpi’s are mostly around 10% from what I’ve seen people report.
My guess is that slower systems/connections do see more of an impact on the numbers, but as I mentioned previously the impact on actual successful transfers is much lower than these numbers suggest.

Please, replace to --mount asap: https://documentation.storj.io/setup/cli/storage-node#running-the-storage-node
https://documentation.storj.io/resources/faq/how-do-i-change-my-parameters-such-as-payout-address-allotted-storage-space-and-bandwidth

This is not a Unraid way, it’s community app with a bug.
The Unraid itself have a bug too - it run containers before the filesystem becomes available.
It corrupt sqlite databases without a reason.
You can read what you can expect with unraid: https://forum.storj.io/tag/unraid

I will work on this, thanks.

At the moment, this script displays anything but real data.
Its bug storj developers

There is no bug, the script is calculating from logs. Those logs got removed with container. So, you can calculate stat only from the last recreation of the container.
If you think there is bug, please, provide steps to reproduce.

Regarding low rate on Unraid it’s common thing, as you can see there: https://forum.storj.io/tag/unraid

1 Like