It’s multivariate…
Absolute distance is important, but also relative node speed within one’s own local neighborhood of nodes.
Of course, with an average failure time of around 2 seconds, the local neighborhood seems to be more important than the absolute distance… which is a bit counter-intuitive, and not what I expected when I first starting running a node.
Anyone of the Raspberry owner try to chance this settings?
# Maximum number of simultaneous transfers
storage2.max-concurrent-requests: 7
Maybe here we can find a good value for some raspberry Nodes.
I know, the value of one is not the best for the other, but maybe someone have good results whit this, so that other can play whit this too.
I can try but I don’t think it would do much difference.
I’ve played with it in the past, with no major changes on traffic performance.
I know that this is not the best way to reach a high accept value. But maybe if you get up from 10% to 15% i think its a good way for Raspberry Node owners. Maybe we can chance here a little bit and there a little bit 
If you can try to play whit this, it would be nice to hear the results
Sure, no worries. I’ll set it on my rpi nodes and post the results.
Meanwhile, just adding to it, just assembled another node, a DC8000 on a 30/30 connection, and it’s already outperforming my Pi (my oldest node) running on a 100/100 ISP.
So I’m getting pretty convinced that PIs are just way to slow for the network demand now. It’s getting more serious by the week 
this parameter shold be commented, it lower your node posibilities.
I can no longer edit my original post, but with the implementation of dRPC the answer to the question posed there has become much simpler.
NO! You should not use this setting at all anymore. It has been mostly deprecated and it could negatively impact your node. Keep that line commented out.
My understanding is that not all pieces are equally profitable
RPi on a good connection can catch 15% of pieces but these are likely larger. 85% that it didn’t win the race for are likely smaller. Nobody knows which of them users will download more frequently but if all are equally probable then winning larger pieces will generate more revenue.
It should be relatively easy to verify. Pieces are regular files. Just compare the average size of all files in the blobs/ directory modified within one day on RPi with 15% success rate and a big server with 60+% rate.
I finally got round to trying vetted storagenode on 64 bit on pi 4.
There’s no improvement.
They can’t compete with bigger powerful machines and the traffic is low now, so they just get some little pieces.
Nevertheless, it’s a inexpensive solution, so just let it run 
How do you get this stat?
I also have a RaspberryPi4 with 4GB
Here is my result with a 50/10 connection in a German village xD
What kind of setup do you have? (SSD? raid? etc)
Which OS is installed?
Did you do any specific configurations to optimize results?
Oh sorry.
My Rpi4 now runs again with Raspian Lite, had Ubuntu Server x64 on it for several months and had several problems and higher cancel rates.
I didn’t optimize the OS, just kicked out all the unnecessary packages and deactivated swapping. The normal HDDs are connected via USB3 with an external power supply.
nice, thanx! I presume u have Raspbian Buster Lite ?
Im totally noob, which packages did u kick out? and how did u deactivate swapping?
I see that the Rasbian lite is 32 bit only? or does it exist in 64 bit aswell? I need to have it in 64 bit because i plan to use my RPI4 also for the NOIA-network and it requires 64 bit…
Which linux os would you go for?
deactivate swapping:
dphys-swapfile swapoff
apt remove dphys-swapfile
Use 32bit raspbian if you are a noob. You can update the firmware easier from that.
64 bit ubuntu also works quite well but not really for a newbie!
What about TinyCore ?
What type of SD card are you using? I ordered the fastest type recommended: Sandisc Extreme Pro 32GB A1 Class 10
