bb-qq
DS216J - CableMatters USB Adapter r8156 - Working and stable, but slow RX speed
I'm testing the driver on a DS216J NAS, with an USB adapter Cable Matters (Realtek 8156). The link is established as expected at 2.5G and the connection is stable. But the reported iperf3 speed is quite limited in RX: 1.30 GB/s (2.33 GB when transmitting). The test is performed connecting a MacBook to the network using a Realtek 8157 based adapter. When receiving, one of the CPUs goes to 100% and this is probably the bottleneck.
I see the exact same issue. However, I'm using a 916+ and a Club 3D CAC-1420 and 2.19.2-2. The RX speed is exactly the same with iperf3 (around 1.3 Gbits/s).
I can confirm that my assumption was right: the same adapter attached to a DS223 delivers 2.30 Gbit/s in both directions and the CPU is not maxed out. It's just matter of providing a decent CPU and everything works fine.
Hm, I don't think that's the case here. The 916+ has a Intel Pentium N3710 which should have plenty of power. The CPU is at 32% when running an rsync task.
BTW, I see the same behavior. TX speeds are according to 2.5 Gbits, but RX is still at 1 Gbits.
RX consumes more CPU than TX. I suggest to run a test with iperf3 and, in another window, to show htop. Probably you’ll see one of the CPUs at 100% during RX. I think that the driver runs in single core and when it reaches 100% the maximum possible bandwidth is achieved. In my case, the same USB adapter runs in RX at 1.33 Gb/s on a DS216J and at 2.33 Gb/s on a DS223. In the first case, I’ve one of the two cores at 100%. In the second case none of the four cores is stressed. In TX it runs at 2.33 Gb/s on both boxes.
I just checked and you are completely right. One CPU is constantly maxed out. I had no idea that 2.5Gbits can eat so much resources. And I totally had thought that the driver is multicore aware.
@bb-qq is there any chance to modify / compile the driver for multicore?
If the code of the driver is not written for supporting a multithreaded execution, just recompiling is not enough. By the way, I suppose that all the modern CPUs (after 2020) are powerful enough to effectively run this driver in a single core.
Offloading processing to the core is performed on the Linux kernel side, so there is nothing that can be done on the driver side.
In general, increasing the MTU size tends to reduce USB transactions and alleviate CPU load. It is unclear whether this will be effective, but if you have not already done so, please try it.
disable shared folder encryption. It eats one core and moving data to nas will be really slow.
For testing: simply create a shared folder without encryption.
