have you tried testing it with iperf3 yet?
How about the hdparm to the harddrive to ensure that it isn’t a chokepoint
What is the drive partitioned as NTFS or EXT3/4? lsusb -t
To see if the drive is actually connecting to the RPi board at USB3 or or USB 2 speeds
Jeff Geerling did some testing
Samba is a cpu heavy sharing service…RPi is a computer…but is also an anemic processor, also the HDD might not be running at full USB speeds…USB2.0 is what theoretical 480Mb/s…so what 60~MB/s
It’s EXT4 (it’s my boot drive – I don’t use SD card):
df -Th | grep "^/dev"
/dev/root ext4 740G 95G 615G 14% /
/dev/sda1 vfat 127M 32M 95M 26% /boot
...
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 264191 262144 128M c W95 FAT32 (LBA)
/dev/sda2 264192 1574961151 1574696960 750.9G 83 Linux
USB is 3.0:
lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
It’s supposed to be UASP (WD EasyStore drive - Ultrastar inside), but the controller is probably blacklisted because it doesn’t operate in USP mode. Regardless, the drive is plenty fast - 202+ MB/s:
dd if=/dev/sda of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 5.19039 s, 202 MB/s
–
have you tried testing it with iperf3 yet?
No, not yet. Need to learn what it is first. Thanks.
Looks like connection itself is the bottleneck.
Could you please recommend how to troubleshoot it?
RPi4 sits on my 1Gbs LAN (cat 5 to router), the router is a nice WiFi6 Asus, client is on WiFi, but WiFi is much faster than 200Mbs. Even Ookla speed test over WiFi to internet gets several times that, so WiFi to LAN should be at least that fast.
I will test with Client on wired LAN later though just as a sanity check–to see if there is any weirdness, but even without that it doesn’t make any sense already.
iperf to a wired machine…this way you can isolate if it’s the wifi connection (sectionalize and isolate)
If that’s not the problem…then check the physical wire to the RPi could be the problem (I once had a wire that that was broken…it would connect, show sync…but dataflow was massively screwed up)
well, shit: changing cable on Rpi4 made no difference, BUT wiring the client to the router gave the much-expected 900-960 Mbs. Samba transfer of a 3GB file was also 100-110 MBs (~900 Mbs).
WTF is this wretched magic? How is it that Ookla was giving 350-460 Mbs speed via WiFi, but connection to Pi was strictly 200 Mbs over the same WiFi??? Was the router doing some stupid de-prioritization of WiFi traffic from client to Pi?
I wasted so much time troubleshooting this before I made this post! Fing Asus!
The wifi of RPi 4 is known to be bad (but better as in the 3B+), due to several factors, like antenna positioning and it’s only one antenna, so you can’t use multiple streams etc.
So 200 mbps are pretty good, for higher speeds you need to use ethernet.
Went into QOS, prioritized Rpi and client PC - still same shit over WiFi.
Cherry on top: devices (RPi included) drop out from the network map randomly – they still work, but intermittently do not show up in QoS, Network Map, etc.
(and that’s with Pi being MAC-bound to its IP !)
Ookla speed of 460 Mbs means that client was able to communicate with the router at least at that speed over WiFi. That was the same router that was routing traffic to RPi4. Why could it route traffic from client to internet (which is far more bottlenecked than LAN) at 460 Mbs, but same router could deliver traffic to the RPi on local LAN only at 200 Mbs? It doesn’t make any sense.
if packet loss or antenna positioning was slowing down my connection all the way down to 200 Mbs then the speed would varry (and would be the same between Internet/Ookla and Rpi4), but it was 200Mbs sharp on the dot over several weeks for Rpi and 360-470 for Internet/Ookla.
So the RPi is connected via cable to the router, another client is connected via wifi to the router. And the conenction between RPI and client is slow. The wifi is not the bottle neck, because between client and router it get’s faster as between client and RPi?! And the RPI wifi is not involved at all?!
Correct - that’s the thing: RPi wifi is not involved at all. In fact, I believe I disabled it when I installed the OS. The Pi is happily connected to the router via cat5 cable.
It’s about the number of parallel threads. Ookla speed test is using multiple channels to perform the test, while Samba is using just one. Within Ookla you should be able to switch between multiple and single connections.