Slow SAMBA (25 MBs) on RPi 4 (8GB)

1Gbe LAN, 800 Mbs WiFi, 220 MBS HDD, and yet SMB trasfer is only 25-30 MBs.

When I transfer it for a while CPU hovers between ~39-70% and temp reaches 70 eventually.
Speeds are slow even before the CPU heats up.

The HDD is fast - 220 MBs (just tested with DD) and is connected via USB3, no other USB devices.

Is it normal? How can I troubleshoot?


just tried sftp using Filezilla – even worse: 8MBs.
BTW, I test on single huge files (3GB), so it’s not due to small file size.

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

Also…USB storage stuff has been a sticking point for RPi

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.

Good call on iPerf:

C:\Users\user\Downloads\iperf-3.1.3-win64\iperf3.exe -c
Connecting to host, port 5201
[  4] local port 31747 connected to port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.01   sec  22.5 MBytes   187 Mbits/sec
[  4]   1.01-2.01   sec  23.8 MBytes   200 Mbits/sec
[  4]   2.01-3.00   sec  22.4 MBytes   189 Mbits/sec
[  4]   3.00-4.01   sec  20.4 MBytes   170 Mbits/sec
[  4]   4.01-5.00   sec  23.4 MBytes   197 Mbits/sec
[  4]   5.00-6.00   sec  24.1 MBytes   202 Mbits/sec
[  4]   6.00-7.00   sec  23.0 MBytes   193 Mbits/sec
[  4]   7.00-8.01   sec  25.0 MBytes   208 Mbits/sec
[  4]   8.01-9.00   sec  24.1 MBytes   204 Mbits/sec
[  4]   9.00-10.00  sec  25.0 MBytes   209 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.00  sec   234 MBytes   196 Mbits/sec                  sender
[  4]   0.00-10.00  sec   234 MBytes   196 Mbits/sec                  receiver

iperf Done.

C:\Users\user\Downloads\iperf-3.1.3-win64\iperf3.exe -c -R
Connecting to host, port 5201
Reverse mode, remote host is sending
[  4] local port 31757 connected to port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec  18.0 MBytes   151 Mbits/sec
[  4]   1.00-2.00   sec  24.6 MBytes   206 Mbits/sec
[  4]   2.00-3.00   sec  22.6 MBytes   190 Mbits/sec
[  4]   3.00-4.00   sec  25.1 MBytes   211 Mbits/sec
[  4]   4.00-5.00   sec  24.9 MBytes   209 Mbits/sec
[  4]   5.00-6.00   sec  24.3 MBytes   204 Mbits/sec
[  4]   6.00-7.00   sec  25.6 MBytes   215 Mbits/sec
[  4]   7.00-8.00   sec  25.2 MBytes   211 Mbits/sec
[  4]   8.00-9.00   sec  24.9 MBytes   209 Mbits/sec
[  4]   9.00-10.00  sec  22.9 MBytes   192 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   239 MBytes   201 Mbits/sec    0             sender
[  4]   0.00-10.00  sec   238 MBytes   200 Mbits/sec                  receiver

iperf Done.

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.

Thank you!

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!

Thank you for your help! :smiling_face_with_tear:

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.

Like I said, it makes no sense.
I’ll probably try Merlin firmware for the Asus router this weekend. See if that fixes this nonsense.

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.

when I connected client PC via cat5 , smb was 900+ Mbs. So, it utilized full bandwith there, but not over wifi? why?

I had same slow issue on R Pi 5, and I eventually improved it by changing to FTP protocol.
when use SMB, transfer speed ~ 25MB/s max, but it increase to ~60MB/s when changed it to FTP, this is fast enough for my use case.

though FTP is not secure,but I only use it within my home private network. besides, my apple TV Infuse support FTP.

You may try FTP if SMB is not a must.

BTW, I also tried SFTP, but it even slower than SMB…

good luck

You could try NFS as well.