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%
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.
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.
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: Storage Node - Storj Docs
How do I change values like wallet address or storage capacity? - Storj Docs
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: Topics tagged 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