USB3.0 HDD issues

Since the bug report is frozen, any other recomendations are welcome, no matter if it only fixes the speed for one case

Uh.....I don't know what you're capable of...

but if you want you can try to fix it yourself :smiley:

just throwing out an idea...

  • find a better working usb driver from another linux kernel source and turn it into a kmod using OpenWRTs toolchain?

I got some news! I tried to copy 3 files at the same time to see total capacity and guess what? Copying 3 files gives me 25MBps each, and copying 4 files gives me 18MBps each so it seems that total capacity may be around 75MBps more or less, so now I guess that the issue may be with samba, because it don't use full speed when you test copying one big file, 75MBps it a lot more reasonable speed considering that the disk is capable of 100MBps (perhaps there is a 25% of samba overhead)

Any ideas of what could be the cause of that issue? The test was made copying files from samba share to my PC

Well its very possible that samba is the only problem. Try to use a higher level tool to test the actual limits of the setup, using something like iperf3 between the router and another linux machine (I'm sure there are other options too).

Yup, with iperf I measure 1 gigabit speed with no problems in both sides, so the problem is samba for sure, but I am not being able to find which config is wrong

75 MB/s is 600 mbps, which isn’t shabby over wireless.

It is not wireless, my PC goes with LAN cable to the router and the HDD is plugged via USB, plus the main issue now is that I cannot get 75MB/s for a single big file transfer, several parallel transfers are needed to use that BW

echo 1 > /proc/sys/net/ipv4/tcp_sack
echo 1 > /proc/sys/net/ipv4/tcp_window_scaling
echo 256960 > /proc/sys/net/core/rmem_max
echo 256960 > /proc/sys/net/core/wmem_max
echo 256960 > /proc/sys/net/core/rmem_default
echo 256960 > /proc/sys/net/core/wmem_default

ethtool -K eth1 tx-generic-segmentation off
echo 256 > /proc/sys/net/core/somaxconn
echo 2560 > /proc/sys/net/core/netdev_max_backlog
echo 0 > /proc/sys/net/ipv4/tcp_slow_start_after_idle
cat /proc/`pidof smbd`/limits
cat /proc/`pidof smbd`/status
hdparm -B 255 /dev/sdX

Then suggests eliminating any USB, disk or network bandwidth issue, and I tend to suspect samba as you do.

Do a test with SCP to see if that gives a conclusive result.

Have you benchmarked the disk itself with hdparm on the router

opkg update
opkg install hdparm
hdparm -Tt /dev/sda

Also you will probably need to tune samba.

I think if multiple simultaneous copy operations are significantly faster than a single operation, then the disk is not the bottleneck (presuming we are talking about a HDD).

Tested, and situation is the same.

Added a new test, when I copy the same big file to my nvme drive and then try with a sata drive (local HDD of the PC) I noticed that I have 50MB/s for a big file to the nvme drive and 25MB/s to the sata HDD, both drives are NTFS formatted as well ass the origin HDD

1 Like

1st of all wrt3200 doesn't support uas, so the driver falls back to a legacy mode.
2nd - try measuring with ftp server instead of samba

If you want to do reliable benchmarking of the disk use fio.
Samba doesn't normally split sessions over multiple CPUs/cores so if you have a router with high load for whatever reason you will see a reduction in overall performance.

Tested with a nfs share on the same disk and performance was excellent!! 110MB/s read and 35MB/s write (same as local speed of disk on router). So problem is 100% samba for sure, maybe any speed tuning is required?

Issue solved, I will let the solution here if other faces the same problem, the fact was that I was mounting shares via dolphin GUI (no idea how dolphin manages that) I configured my shares for mounting at fstab and I get full speed, I copy files at same speed from router to HDD as well as from PC to HDD via samba.

Download speed is 110MB/s aprox (read speed on disk)
Upload speed is 35MB/s aprox (write speed on disk)
That "slow" upload speed is the same as we measured with dd before, will wait for better USB3 support on the open bug for that

dolphin relies on a cifs kioslave, a simple -and slow- userspace implementation of the cifs protocol for the KDE desktop environment.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.