Late last month, I received hardware to test 2.5GbE and WiFi 6 with namely a Radxa E25 SBC, Xiaomi AX6000 WiFi 6 router, and an 8-port TP-Link 2.5GbE switch. I intended to start testing 2.5GbE networking with UP Xtreme i11 mini PC and Radxa E25, but I thought it might be a good idea to get a USB 3.0 to 2.5Gbps Ethernet adapter just in case.
I purchased a no-name dongle for under $15 (475 THB on Lazada) in Thailand, but a USB 3.0 dongle that looks exactly the same can also be purchased on Aliexpress with either a USB Type-A port or a USB Type-C port. There’s some issue with Radxa E25 (it won’t boot it), so I ended up testing the dongle with UP Xtreme i11 mini PC.
USB 3.0 to 2.5Gbps Ethernet adapter unboxing
The package, marked “USB to LAN Gigabit Ethernet Adapter”, has “USB 3.0” and “2.5 Gbps” ticked, a good sign since it is just what I ordered…
The dongle comes with a driver CD, but I did not use it as I connected the dongle to my laptop running Ubuntu 20.04.
2.5GbE USB dongle teardown: RTL8156B inside
I’ve done all testing first before taking it apart, but let’s show the photos of the internals to see exactly what we have here.
The adapter is based on Realtek RTL8156B “10/100/1000M/2.5G Ethernet controller for USB 3.0 applications”, and a low-profile RJ45 jack that makes it fairly thin (for a USB Ethernet adapter).
The back of the XHT156B v2.0 board has an unpopulated footprint with 8 pins. The description of the Realtek chips states that “The RTL8156B(S) features embedded One-Time-Programmable (OTP) memory that can replace the external EEPROM (93C46/93C56/93C66)”. So that must be the footprint for external EEPROM, as for instance, 93C46 EEPROM is available in various 8-pin packages
Info in Ubuntu 20.04
The first time I inserted the adapter into the USB 3.0 port of my laptop, I thought it had some issues as I could not find any new USB messages in dmesg. It turned out there were just some delays, as the Realtek USB LAN device showed up with lsusb:
1 2 3 4 5 6 7 8 9 10 |
lsusb Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 003: ID 046d:c534 Logitech, Inc. Unifying Receiver Bus 003 Device 002: ID 0408:a031 Quanta Computer, Inc. VGA WebCam Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 004: ID 0bda:8156 Realtek Semiconductor Corp. USB 10/100/1G/2.5G LAN Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 004: ID 04ca:3015 Lite-On Technology Corp. Bus 001 Device 011: ID 046d:c542 Logitech, Inc. Wireless Receiver Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub |
I did notice some warnings/errors? in /var/log/syslog:
1 2 3 4 5 |
Feb 14 17:04:42 cnx-laptop-4 NetworkManager[1114]: <info> [1644833082.0081] settings: (enx1cbfced40321): created default wired connection 'Wired connection 2' Feb 14 17:04:42 cnx-laptop-4 mtp-probe: checking bus 1, device 10: "/sys/devices/pci0000:00/0000:00:08.1/0000:04:00.3/usb1/1-2" Feb 14 17:04:42 cnx-laptop-4 mtp-probe: bus: 1, device: 10 was not an MTP device Feb 14 17:04:42 cnx-laptop-4 systemd-udevd[54394]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable. Feb 14 17:04:44 cnx-laptop-4 ModemManager[1235]: <info> [base-manager] couldn't check support for device '/sys/devices/pci0000:00/0000:00:08.1/0000:04:00.3/usb1/1-2': not supported by any plugin |
But as I connected the USB dongle to the switch, and check information with inxi, the link was up:
1 2 3 4 5 6 7 8 9 10 11 |
inxi -n Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 IF: enp2s0f1 state: down mac: 98:28:a6:0f:06:07 Device-2: Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter driver: ath10k_pci IF: wlp3s0 state: up mac: 70:c9:4e:b7:84:77 Device-3: Realtek USB 10/100/1G/2.5G LAN type: USB driver: cdc_ncm IF: enx1cbfced40321 state: up speed: 2500 Mbps duplex: half mac: 1c:bf:ce:d4:03:21 |
That’s a 2500 Mbps link but only at half-duplex, so I’ll just skip the full-duplex test I normally do with iperf.
Back to the kernel log with dmesg:
1 2 3 4 5 6 7 8 9 10 |
[29818.749904] usb 2-1: new SuperSpeed USB device number 4 using xhci_hcd [29818.770326] usb 2-1: New USB device found, idVendor=0bda, idProduct=8156, bcdDevice=31.00 [29818.770336] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=6 [29818.770341] usb 2-1: Product: USB 10/100/1G/2.5G LAN [29818.770344] usb 2-1: Manufacturer: Realtek [29818.770347] usb 2-1: SerialNumber: 0013000000 [29818.836184] cdc_ncm 2-1:2.0: MAC-Address: 1c:bf:ce:d4:03:21 [29818.836192] cdc_ncm 2-1:2.0: setting rx_max = 16384 [29818.836253] cdc_ncm 2-1:2.0: setting tx_max = 16384 [29818.836707] cdc_ncm 2-1:2.0 eth0: register 'cdc_ncm' at usb-0000:04:00.3-1, CDC NCM, 1c:bf:ce:d4:03:21 |
As a side note, I’m using Xiaomi AX6000 as the DHCP server, but I have no wired internet in my current location (only through a 4G LTE WiFi modem without RJ45 port), so I have to tick “Use this connection only for resources on its network” in both IPv4 and IPv6 tabs to prevent my laptop from accessing the Internet from the USB LAN port.
2.5GbE testing with UP Xtreme i11
Once everything is connected we can easily check whether all interfaces are using a 2500 Mbps link by checking the LEDs on the TP-Link switch.
If the left LED is green, we have a 2500 Mbps link, if the right LED is green that’s 1000 Mbps, and the orange color would indicate lower speeds (100M/10M). The three connections are then 2500 Mbps. All good!
Since access to the Xiaomi AX6000 router’s interface or/and mobile app only works when the Internet is connected, I had to find another method to list the host in the LAN. I used nmap in a terminal window:
1 2 3 4 5 6 7 8 9 |
nmap -sP 192.168.31.0/24 Starting Nmap 7.80 ( https://nmap.org ) at 2022-02-14 19:39 +07 Nmap scan report for 192.168.31.1 Host is up (0.0031s latency). Nmap scan report for 192.168.31.12 Host is up (0.0019s latency). Nmap scan report for cnx-laptop-4 (192.168.31.166) Host is up (0.00014s latency). Nmap done: 256 IP addresses (3 hosts up) scanned in 2.96 seconds |
192.168.31.1 is the router, 192.168.31.166 is my laptop, so 192.168.31.12 must be UP Xtreme i11 mini PC…
The mini is also running Ubuntu 20.04, so we can compare the output of inxi:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
devkit@UPX-i11:~$ inxi -n Network: Device-1: Intel Ethernet I219-LM driver: e1000e IF: eno1 state: down mac: 00:07:32:89:ef:c3 Device-2: Intel driver: igc IF: enp44s0 state: up speed: 2500 Mbps duplex: full mac: 00:07:32:89:ef:c2 IF-ID-1: cni0 state: up speed: 10000 Mbps duplex: unknown mac: e6:f7:bf:cd:87:ae IF-ID-2: docker0 state: down mac: 02:42:ab:5f:2b:57 IF-ID-3: flannel.1 state: unknown speed: 2500 Mbps duplex: full mac: 3a:a0:1f:c2:55:45 IF-ID-4: veth0f359f7f state: up speed: 10000 Mbps duplex: full mac: 52:a2:26:ea:ce:36 IF-ID-5: veth167c9fcb state: up speed: 10000 Mbps duplex: full mac: f6:0a:7c:50:a2:dc IF-ID-6: veth515ebe48 state: up speed: 10000 Mbps duplex: full mac: 92:3d:0a:03:c4:dc IF-ID-7: veth655cbd04 state: up speed: 10000 Mbps duplex: full mac: 76:19:ff:ff:52:d5 IF-ID-8: veth81914ed8 state: up speed: 10000 Mbps duplex: full mac: 26:3f:f5:21:18:8e |
enp44s0 interface is up with a 2500 Mbps, full-duplex link.
Let’s run iperf to test “upload” speed from laptop to mini PC:
1 2 3 4 5 6 7 8 |
iperf -t 60 -c 192.168.31.12 ------------------------------------------------------------ Client connecting to 192.168.31.12, TCP port 5001 TCP window size: 1.39 MByte (default) ------------------------------------------------------------ [ 3] local 192.168.31.166 port 41050 connected with 192.168.31.12 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-60.0 sec 16.4 GBytes 2.35 Gbits/sec |
2.35 Gbps on average with some peaks close to 2.46 Gbps. That’s a resounding pass.
Let’s switch to “download” from mini PC to laptop.
1 2 3 4 5 6 7 8 |
iperf -t 60 -c 192.168.31.166 ------------------------------------------------------------ Client connecting to 192.168.31.166, TCP port 5001 TCP window size: 221 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.31.12 port 52974 connected with 192.168.31.166 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-60.0 sec 4.13 GBytes 591 Mbits/sec |
Now that’s disappointing at just under 600 Mbps. That’s worse than what we would expect from Gigabit Ethernet.
Let’s try again, but this time with iperf3 upload:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
iperf3 -t 60 -c 192.168.31.12 -i 5 Connecting to host 192.168.31.12, port 5201 [ 5] local 192.168.31.166 port 59878 connected to 192.168.31.12 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-5.00 sec 1.37 GBytes 2.36 Gbits/sec 0 1.57 MBytes [ 5] 5.00-10.00 sec 1.37 GBytes 2.35 Gbits/sec 0 1.65 MBytes [ 5] 10.00-15.00 sec 1.37 GBytes 2.35 Gbits/sec 1 1.75 MBytes [ 5] 15.00-20.00 sec 1.37 GBytes 2.35 Gbits/sec 0 1.81 MBytes [ 5] 20.00-25.00 sec 1.37 GBytes 2.35 Gbits/sec 0 2.53 MBytes [ 5] 25.00-30.00 sec 1.37 GBytes 2.35 Gbits/sec 0 2.53 MBytes [ 5] 30.00-35.00 sec 1.37 GBytes 2.35 Gbits/sec 0 2.53 MBytes [ 5] 35.00-40.00 sec 1.37 GBytes 2.36 Gbits/sec 0 2.53 MBytes [ 5] 40.00-45.00 sec 1.37 GBytes 2.35 Gbits/sec 0 2.53 MBytes [ 5] 45.00-50.00 sec 1.37 GBytes 2.35 Gbits/sec 0 2.53 MBytes [ 5] 50.00-55.00 sec 1.37 GBytes 2.35 Gbits/sec 0 2.53 MBytes [ 5] 55.00-60.00 sec 1.37 GBytes 2.35 Gbits/sec 0 2.53 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 16.4 GBytes 2.35 Gbits/sec 1 sender [ 5] 0.00-60.04 sec 16.4 GBytes 2.35 Gbits/sec receiver iperf Done. |
and iperf3 download:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
iperf3 -t 60 -c 192.168.31.166 -i 5 Connecting to host 192.168.31.166, port 5201 [ 5] local 192.168.31.12 port 57138 connected to 192.168.31.166 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-5.00 sec 357 MBytes 599 Mbits/sec 121 84.8 KBytes [ 5] 5.00-10.00 sec 343 MBytes 576 Mbits/sec 123 91.9 KBytes [ 5] 10.00-15.00 sec 351 MBytes 589 Mbits/sec 110 72.1 KBytes [ 5] 15.00-20.00 sec 364 MBytes 611 Mbits/sec 124 133 KBytes [ 5] 20.00-25.00 sec 371 MBytes 622 Mbits/sec 145 72.1 KBytes [ 5] 25.00-30.00 sec 363 MBytes 608 Mbits/sec 124 157 KBytes [ 5] 30.00-35.00 sec 359 MBytes 603 Mbits/sec 107 117 KBytes [ 5] 35.00-40.00 sec 344 MBytes 577 Mbits/sec 94 151 KBytes [ 5] 40.00-45.00 sec 362 MBytes 607 Mbits/sec 108 107 KBytes [ 5] 45.00-50.00 sec 352 MBytes 591 Mbits/sec 123 126 KBytes [ 5] 50.00-55.00 sec 372 MBytes 625 Mbits/sec 102 109 KBytes [ 5] 55.00-60.00 sec 346 MBytes 581 Mbits/sec 105 158 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 4.18 GBytes 599 Mbits/sec 1386 sender [ 5] 0.00-60.00 sec 4.18 GBytes 599 Mbits/sec receiv |
So it does not matter whether we use iperf2 or iperf3, the results are the same.
Let’s investigate a bit more by using the Gigabit Ethernet port of my laptop to the 2.5 GbE port of Xtreme i11. iperf3 download (mini PC to laptop):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
iperf3 -t 60 -c 192.168.31.199 -i 5 Connecting to host 192.168.31.199, port 5201 [ 5] local 192.168.31.12 port 55246 connected to 192.168.31.199 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-5.00 sec 564 MBytes 947 Mbits/sec 0 742 KBytes [ 5] 5.00-10.00 sec 561 MBytes 942 Mbits/sec 0 781 KBytes [ 5] 10.00-15.00 sec 561 MBytes 942 Mbits/sec 0 1.12 MBytes [ 5] 15.00-20.00 sec 561 MBytes 942 Mbits/sec 0 1.12 MBytes [ 5] 20.00-25.00 sec 561 MBytes 942 Mbits/sec 0 1.12 MBytes [ 5] 25.00-30.00 sec 561 MBytes 942 Mbits/sec 0 1.12 MBytes [ 5] 30.00-35.00 sec 561 MBytes 942 Mbits/sec 0 1.12 MBytes [ 5] 35.00-40.00 sec 561 MBytes 942 Mbits/sec 0 1.12 MBytes [ 5] 40.00-45.00 sec 561 MBytes 942 Mbits/sec 0 1.12 MBytes [ 5] 45.00-50.00 sec 561 MBytes 942 Mbits/sec 0 1.12 MBytes [ 5] 50.00-55.00 sec 561 MBytes 942 Mbits/sec 0 1.12 MBytes [ 5] 55.00-60.00 sec 561 MBytes 942 Mbits/sec 0 1.12 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 6.58 GBytes 942 Mbits/sec 0 sender [ 5] 0.00-59.99 sec 6.58 GBytes 942 Mbits/sec receiver iperf Done. |
942 Mbps is the speed I would expect, so the issue appears to be related to the USB Ethernet adapter. But to make sure, let’s reverse the test by connecting the USB 3.0 2.5GbE adapter to the Gigabit Ethernet port of UP Xtreme i11 mini PC:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
iperf3 -t 60 -c 192.168.31.166 -i 5 Connecting to host 192.168.31.166, port 5201 [ 5] local 192.168.31.13 port 45862 connected to 192.168.31.166 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-5.00 sec 517 MBytes 868 Mbits/sec 95 939 KBytes [ 5] 5.00-10.00 sec 511 MBytes 858 Mbits/sec 2 826 KBytes [ 5] 10.00-15.00 sec 515 MBytes 864 Mbits/sec 2 730 KBytes [ 5] 15.00-20.00 sec 504 MBytes 845 Mbits/sec 3 566 KBytes [ 5] 20.00-25.00 sec 510 MBytes 856 Mbits/sec 0 964 KBytes [ 5] 25.00-30.00 sec 516 MBytes 866 Mbits/sec 1 1010 KBytes [ 5] 30.00-35.00 sec 518 MBytes 868 Mbits/sec 1 994 KBytes [ 5] 35.00-40.00 sec 512 MBytes 860 Mbits/sec 0 1.25 MBytes [ 5] 40.00-45.00 sec 520 MBytes 872 Mbits/sec 1 1.21 MBytes [ 5] 45.00-50.00 sec 521 MBytes 875 Mbits/sec 2 717 KBytes [ 5] 50.00-55.00 sec 510 MBytes 856 Mbits/sec 1 878 KBytes [ 5] 55.00-60.00 sec 512 MBytes 860 Mbits/sec 2 758 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 6.02 GBytes 862 Mbits/sec 110 sender [ 5] 0.00-60.00 sec 6.02 GBytes 862 Mbits/sec receiver iperf Done. |
826 Mbps! Interesting… Not perfect but faster than the 2.5Gbe to 2.5GbE connection.
iperf does not exactly represent a standard use case. So I’ve connected MINIX NEO Storage Plus USB-C dock with a 480GB SSD to the USB-C “Thunderbolt” port of UP Xtreme Mini PC, and created a SAMBA share, so I could copy a large file to/from the SSD’s from the laptop and mini PC over the 2.5GbE network.
From the laptop to the mini PC the transfer was done at around 750 Mbps.
The mini PC to laptop “download” transfer was also quite slower at under 500 Mbps and ended up with a “software connection abort” transferring only 7.8GB out of the 11.2 GB file.
SAMBA is widely used, but may not be the fastest way to transfer data. Let’s switch to scp transferring the same files from the laptop to the mini PC.
1 2 3 4 5 6 7 |
time scp Libero_SoC_v2021.2_lin.bin devkit@192.168.31.12:/home/devkit/NEO_Storage devkit@192.168.31.12's password: Libero_SoC_v2021.2_lin.bin 100% 10GB 107.8MB/s 01:38 real 1m42.330s user 0m56.858s sys 0m57.110s |
That’s faster. The 11.2GB was transferred in 98 seconds or about 117 MB/s on average (963 Mbps).
Let’s delete the file on the source, and copy it back from the mini PC to the laptop.
1 2 3 4 5 6 7 |
time scp devkit@192.168.31.12:/home/devkit/NEO_Storage/Libero_SoC_v2021.2_lin.bin . devkit@192.168.31.12's password: Libero_SoC_v2021.2_lin.bin 100% 10GB 100.3MB/s 01:46 real 1m49.093s user 0m59.326s sys 0m55.003s |
A bit slower, but not that bad at around 108.2MB/s on average (865.6 Mbps). I’m not quite sure why scp will show the file size to be 10GB, as it is 11.2GB in Nautilus or 11GB from the terminal:
1 2 |
ls -lh /Download_SSD/Libero_SoC_v2021.2_lin.bin -rwxr-xr-x 1 jaufranc jaufranc 11G Feb 16 16:00 /Download_SSD/Libero_SoC_v2021.2_lin.bin |
I was expecting a higher transfer speed, so that’s disappointing, but about what we should expect for both SAMBA and scp based on a blog post on WirelessMoves. If we want to get a higher speed we can use simpler crypto with scp or/and send the data to /dev/null. Let’s give it a try by downloading the file to /dev/null on my laptop:
1 2 3 4 5 6 7 |
time scp -c aes128-ctr devkit@192.168.31.12:/home/devkit/NEO_Storage/Libero_SoC_v2021.2_lin.bin /dev/null devkit@192.168.31.12's password: Libero_SoC_v2021.2_lin.bin 100% 10GB 67.2MB/s 02:38 real 2m40.012s user 0m24.491s sys 0m39.740s |
Wow! That’s catastrophic… What happened here? Let’s try to transfer from the laptop to the mini PC instead:
1 2 3 4 5 6 7 |
time scp -c aes128-ctr Libero_SoC_v2021.2_lin.bin devkit@192.168.31.12:/dev/null devkit@192.168.31.12's password: Libero_SoC_v2021.2_lin.bin 100% 10GB 140.9MB/s 01:15 real 1m18.061s user 0m17.938s sys 0m55.235s |
That’s more like it. But when we look at a live graph showing network transfer speed there’s a lot of variation.
I’ll have to test the USB 3.0 to 2.5 Gbps Ethernet USB adapter with Radxa E25 to see how it behaves, and maybe there are some settings to adjust to improve performance, but at this time, I believe I should probably not rely on that USB adapter for testing…
Continue reading “Fixing performance issues with Realtek RTL8156B 2.5GbE USB dongle in Ubuntu“.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
Could you use one of these on a Android TV or a Khadas Vim, Odroid and would you get any Ethernet, speed benefit?
The speeds here are disappointing for gigabit Ethernet, let alone 2.5 GbE. Maybe it’s just a driver problem, but until it’s fixed you’re better off using the built-in Ethernet or some other dongle.
Yes, but depends on model.
Odroid H2/H2+: yes, definitely (*)
Odroid N2/N2+: quasi-yes (*)
Odroid C4: slower than N2, but still faster than 1 GbE (*)
(*) In all cases, speeds witnessed with iperf3 are one thing, normal usage is another. If you for instance you copy files, the overall speed will be less due to the speed of other internal buses/components and mostly the speed of the disk I/O. There are applicable mitigations, but you won’t copy files at a pure 2.35 Gbits/sec.
See my other comment with a link to a web page with Samba benchmarking.
Khadas Vim: I don’t know, I don’t have one.
> link to a web page with Samba benchmarking.
Wrt your testing methodology: are you aware that Linux as SMB client is usually the slowest variant possible (at least compared to macOS and Windows 7 onwards that both automagically tune SMB and TCP/IP parameters to optimize throughput. Windows Explorer and Finder even implement parallel streams to increase performance)?
Yes. I did iperf3 to control what theoretical max speed you get (and check that the goddamned thing is working) and then Linux smb client because that’s what I use vs. smb on Windows or MacOS which I don’t use.
So:
Right? If so, that’s quite disappointing.
Looking forward to more tests.
I won’t comment on the Samba and scp tests since testing from bottom to top is the only reasonable way and if things already look weird with iperf3 then there’s no need for further testing layers above 🙂
Iperf3 shows tons of retransmits in one direction. TX/RX use different cable pairs, your setup (with switch) is overly complex since one of two cables or both may be the culprit.
It’s 2022 now, Zeroconf works flawlessly since ages and people still ignore it. An apt install libnss-mdns avahi-autoipd on both Linux boxes is all that’s needed to not ‘need’ any DHCP server any more. Both machines will pick up a link local address from the 169.254/16 range and will be accessible by name.
Simply connect both machines directly with an Ethernet cable and then test from the laptop both directions with
iperf3 -t 60 -c UPX-i11.local ; iperf3 -R -t 60 -c UPX-i11.local
If numbers are bad, exchange (direction of) the Ethernet cable. And looking at ntop and atop output is also a good idea to spot potential bottlenecks or even routing weirdness.
It looks like Zeroconf is enabled/installed by default in Ubuntu 20.04. If I connect an Ethernet cable between the two machines the link is up on my laptop, but I don’t get an IPv4 address only IPv6. ping6 does not seem to work.
By the way, changing the driver helped a lot, but “download” is not perfect yet.
> It looks like Zeroconf is enabled/installed by default in Ubuntu 20.04.
AFAIK Canonical differentiates between ‘server’ and ‘desktop’ versions wrt Zeroconf (probably related to stubborn admins). At least installing libnss-mdns and avahi-autoipd should make things work between both Ubuntu boxes.
When talking about ‘changing the driver’… did you pull in Ubuntu 5.14 kernel or build the RealTek driver?
I explain everything I did in that post: https://www.cnx-software.com/2022/02/20/fixing-performance-issues-with-realtek-rtl8156b-2-5gbe-usb-dongle-in-ubuntu/
Now “download” is up to 1.66 Gbps. I think the driver or hardware may be the issue.
> SAMBA is widely used, but may not be the fastest way to transfer data.
That depends on a lot of things and as always in a client <-> server setup the problem can be on either end of the cable. In your case using Ubuntu/Nautilus and as such gvfs crappy SMB performance is most likely due to gvfs using laughably small block sizes for SMB transfers (I read in the past about something as low as 4K compared to several MB block size when using Windows or macOS where network settings are dynamically tuned to the optimum).
Performance problems could be due to the kernel driver. Under Arch Linux I had to use a out of tree dkms driver to get full performance out of a different RTL8156 based usb dongle https://aur.archlinux.org/packages/r8152-dkms
Since Jean-Luc is on Ubuntu maybe quickly checking out 5.13/5.14 is a good first try. Requires just an apt install linux-oem-20.04d (or linux-oem-20.04c for 5.13).
There’s also the possibility that the chip overheats and throttles, which could match your xfer graph. A coworker is having lots of trouble with an overheating GbE adapter these days, it even disappears from the USB bus! I suggested that maybe if he takes a 2.5G one he’d have more luck at GbE speeds given that they need to achieve higher rate in the same power budget. Your test doesn’t yet encourage to try one, though 😉
The symptom is clearly the
cdc_ncm
driver that is running in compatibility mode. I had the similar results testing RTL based dongles. Picking latest kernel will make it use a new built-in kernel driver and fixes iperf.Hi Jean Luc,
Did you notice that the adapter was showing half duplex at 2.5 gbps?
It is easy to overlook but it is there in the inxi output.
If the switch thinks the interface is full duplex,
but the adapter is thinking it’s half,
that could be the root cause for many of the issues you are seeing.
So, uhh, yeah.
Being there done that a little bit less than 2 years ago when the first adapters showed up on the market. It was a rocky road. First you need to find adapters with the RTL8156B chipset. The RTL8156 non-B was *&^%$#@!
Second it depends on which OS you use: Windows or Linux. I’m only talking about Linux here, my understanding is that the issues are less apparent with Windows.
The issues you can experience are:
The first 3 issues were fixed by switching from the RTL8156 to the RTL8156B. Plus using the driver that works best, and not necessarily the last version(*). Just make sure to use a driver downloaded from the Realtek web site and not the driver that comes with your OS.
There were similar “adventures” with the RTL8125B, the PCIe cousin.
(*) Realtek released numerous versions fixing these issues but a few of them introduced crazy CPU consumption (for the PCIe cousin IIRC.)
The fourth one was fixed by disabling ASPM in the BIOS/UEFI.
Tested at the time on Odroid H2/H2+ plus H2 net card, N2/N2+, C4.
Once I found something that worked, I stopped following the Realtek new driver versions. As long as these driver build with the current kernel (e.g. 5.4.0-97-generic for Ubuntu as this writing) I have no incentive to fix something that ain’t broken. This MEANS Realtek might have released something with no issue and no side effect since.
For more details, see: https://forum.odroid.com/viewtopic.php?f=172&t=38713. You can also search in these forums for “2.5 GbE” or “ASPM” because several users came up with interesting solution and hands-on for other OSes.
CONCLUSION: Remember the saga of the 1 GbE Realtek chipsets? Same thing here. So one can optimistically conclude that Realtek will eventually get it right or has gotten it right now (I didn’t check.)
—
Last but not least, do NOT spend money or time testing USB-3 5GbE adapters. At this point they all use the same ACQ chipset which is USB 3.[1,2] Gen 1, meaning the chipset is 5 Gbps. Try to stuff 5 GbE into a 5 Gbps USB tunnel and obviously it will be a disaster. You get 3.5 Gbits/sec so better than the 2.35 Gbits/sec from 2.5 GbE. But you will never get the the expected/hoped 4.70 Gbits/sec. Still a possible solution if you want more than 2.35 Gbits/sec without going 10 GbE. On the other side, all the vendors are simply lying on the capabilities of these adapters by playing on words: “up to” 5 GbE, except you’ll never reach it.
> Windows or Linux. … my understanding is that the issues are less apparent with Windows.
With macOS no problems and maximum performance even with the initial RTL8156. Driver is part of the OS (since 10.13 IIRC) and as such also available in Recovery Mode and after Internet Recovery (so restoring a whole machine from latest TimeMachine backup on a NAS works without any driver hassles at max performance).
Not if you plug it into a TB 3 or 4 port because the shared bus speed is 40 Gbps, so your much likely to get closer to the advertised speed.
Try increasing MTU on both sides, USB driver is very likely not doing interrupt mitigation thus rising an interrupt for each received data packet rendering data transfer CPU bound.
Same here, newer driver on windows are catastrophic, only 1.4 gb/s, but some older are able to do 2.3/1.4 max speeds (also the newer Linux kernel drivers), so I guess that Realtek it’s the only option for 2.5gbe for now
Half duplex on any Ethernet interface less than 20 years old is the sign something is wrong. All twisted pair variants of Ethernet when used with switches (rather than hubs as could have been the case in the ‘90s) use full duplex. If an interface says half duplex it means the negotiation failed. Unless it was forced (which is never a good idea as it can lead to even more problems if the two ends of the link don’t agree), it means either a hardware problem (cable if you are lucky, bad interface otherwise) or a driver issue.
I would start by replacing the cable if you haven’t already, then try different combinations of devices to isolate which one is having the issue, then try to find updated drivers. If all else fails it’s a hardware issue, you need to have the faulty device replaced.
Note that if one end is forced to full, in some cases that leads the other end to fail the negotiation and then default to half. If you are set to half, anytime you send a frame and the other end sends one at the same time (which it is allowed to since it believes the link is full duplex), then you get a collision and abort TX.
Make sure neither end of the link is forced, or that both are forced to the same duplex setting (ideally full duplex). Anything else will lead to terrible performance.
As others state, have your tried latest Linux Realtex driver ? USB NIC Linux driver for kernel up to 5.6 .
https://www.realtek.com/en/component/zoo/category/network-interface-controllers-10-100-1000m-gigabit-ethernet-usb-3-0-software
Thanks!
Build driver v2.17.1 for r8152 on Ubuntu 22.04.12 LTS with kernel 5.19.0-50-generic fix the problem.
Note: the PCIe 2.5G network card r8169(also from Realtek) still with the same issue(at 2023-08-05), the newest version of the driver is v6.031.00(see https://www.realtek.com/en/component/zoo/category/pci-8169-8110 ) and Ubuntu 22.04.12 LTS with kernel 5.19.0-50-generic already contained this. Hope someone could contract Realtek and report the bug.
Sorry. The
Note
part is wrong. The actual model of PCIe 2.5G network card on my Mini PC Beelink SER6 Pro is r8125(found with commandlspci | grep Eth
).This is how I fixed the 1.5 G upload limit of r8125 2.5G PCIe network card(which Ubuntu use r8169 driver incorrectly):
sudo rmmod r8169
sudo mv /lib/modules/5.19.0-50-generic/kernel/drivers/net/ethernet/realtek/r8169.ko <span style="color: rgb(119, 119, 119);">/lib/modules/5.19.0-50-generic/kernel/drivers/net/ethernet/realtek/r8169.ko</span>
sudo bash -c 'echo "blacklist r8169" >> /etc/modprobe.d/blacklist-ethernet.conf'
sudo reboot
And use command
inxi -n
to check driver of device ‘Realtek RTL8125 2.5GbE’ isr8125
Won’t help you have a cracked shielded inductor on the top left (labelled C).