Low download percentage

With the below results, what would be some things to look into and the commands to do so?

========== AUDIT =============
Successful: 3626
Recoverable failed: 0
Unrecoverable failed: 0
Success Rate Min: 100.000%
Success Rate Max: 100.000%
========== DOWNLOAD ==========
Successful: 14969
Failed: 66135
Success Rate: 18.456%
========== UPLOAD ============
Successful: 123062
Rejected: 0
Failed: 14113
Acceptance Rate: 100.000%
Success Rate: 89.712%
========== REPAIR DOWNLOAD ===
Successful: 17
Failed: 0
Success Rate: 100.000%
========== REPAIR UPLOAD =====
Successful: 766
Failed: 13
Success Rate: 98.331%

try netdata docker container to detect issues with your node.

Low internet speed?

Basic / low powered hardware?

Do i type in those three words?

https://hub.docker.com/r/netdata/netdata

Ohh gotcha, install something to monitor…

The uploads and repair traffic all look fine, it’s just the downloads. I haven’t been monitoring the forum like I used to and just logged into the node for the fist time since version 27 days…
I didn’t know if there was something known, or a way to monitor the uncapped concurrent sessions, or something I should check or change to help the downloads recover -like concurrent sessions…

Just ran
sudo docker exec -it storagenode grep concurrent /app/config/config.yaml

Set to 6 currently

Read through some other postings…
Maybe it is being impacted by the upload testing and it is being saturated and causing it to lose the download race???

Just seems like a high number of fails to accumulate within the recent tests time window. Like I said I haven’t checked it in a while.

Where are others setting concurrent sessions to on a Pi4 now days? Or with release notes about uncapped concurrent sessions, are they working on Pi4s?

Please, comment out this parameter, it’s deprecated
The low download rate is related to cut of long tail:

It’s applied to uploads and downloads as well
With other words your node loose the race for pieces to competitors - nodes which is more fast and closest to the customer.

I get that it is happening because I lost the race…
I just wanted to confirm it wasn’t due to a different reason. Some of the other posts I read were referencing link saturation due to heavy node uploads due to current testing models. So if I am busy uploading, I won’t be able to handle downloading as efficiently… or atleast that is my interpretation

How do you get that information? Is there a CLI tool?

There is a script that @BrightSilence made.
I am on phone so I cant search the forum for it. Look for keyword successrate

It’s here https://github.com/ReneSmeekes/storj_success_rate

upload doesn’t affect download. They are mutually exclusive. The small bytes of data for each block are tiny compared to the large block of upload download data. It is a race and download bandwidth can mean you lose out and your piece didn’t get there in time. Also, overall network bandwidth is a factor. Ping time to/from the client can be large. But on your node, what is your link speed? I am at 10/100 Mbps and my downloads lose out a lot. I’ll have 2-6 files transfer and my limit is 10 Mbps. so I get a lot of context cancelled. Even with that some small files get through relatively quickly and succeed when larger files fail. My uploads are much more successful at 100 Mbps with multiple simultaneous transfers, yet there are a few context cancelled there too.

The best tool is to watch the log live and see what wins and loses. If there are successful downloads and uploads, everything is working fine. Plus keep an eye on what satellites they are. Some satellites are more successful for my node than others.