Posted on by Jean-Luc Aufranc (CNXSoft) - 28 Comments on USB 3.0 to 2.5Gbps Ethernet adapter review

USB 3.0 to 2.5Gbps Ethernet adapter review

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

USB to LAN 2.5Gbps Ethernet Adapter

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…

USB to LAN 2.5 Gigabit Ethernet Adapter

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.

RTL8156B adapter

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).

2.5GbE USB 3.0 dongle

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:


I did notice some warnings/errors? in /var/log/syslog:


But as I connected the USB dongle to the switch, and check information with inxi, the link was up:


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:


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.

use this connection only for-resources on its network

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.

TP-Link 2.5GbE LEDs

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:


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:


enp44s0 interface is up with a 2500 Mbps, full-duplex link.

Let’s run iperf to test “upload” speed from laptop to mini PC:


 

usb3 2.5gbe dongle upload speed

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.


usb 3.0 2.5gbe dongle download speed

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:


and iperf3 download:


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):


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:


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.

SAMBA 2.5GbE Laptop to Mini PC

From the laptop to the mini PC the transfer was done at around 750 Mbps.

SAMBA 2.5GbE Mini PC to LaptopThe 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.

SCP 2.5GbE Laptop to Mini PC


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.

SCP 2.5GbE Mini PC to Laptop


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:


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:


Wow! That’s catastrophic… What happened here? Let’s try to transfer from the laptop to the mini PC instead:


That’s more like it. But when we look at a live graph showing network transfer speed there’s a lot of variation.

2.5GbE network throughput

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“.

Share this:
FacebookTwitterHacker NewsSlashdotRedditLinkedInPinterestFlipboardMeWeLineEmailShare

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress

ROCK Pi 4C Plus

28 Replies to “USB 3.0 to 2.5Gbps Ethernet adapter review”

  1. Could you use one of these on a Android TV or a Khadas Vim, Odroid and would you get any Ethernet, speed benefit?

    Reply

    1. 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.

      Reply

    2. 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.

      Reply

      1. > 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)?

        Reply

        1. 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.

          Reply

  2. So:

    • most test max out at 100 MB/s (instead of 250 MB/s).
    • one test achieved 140 MB/s

    Right? If so, that’s quite disappointing.

    • dongle hardware problem?
    • Linux driver problem?
    • test setup problem?
    • cabling problem? Maybe the cable is too bad for 2.5GBASE-T, and it downgrades to good old 1Gbps?
    • switch problem? Despite the green LED.
    • … ?

    Looking forward to more tests.

    Reply

  3. 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.

    Reply

    1. 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.

      Reply

      1. > 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?

        Reply

  4. > 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).

    Reply

    1. 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).

      Reply

  6. 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 😉

    Reply

    1. 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.

      Reply

  7. 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.

    Reply

    1. 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.

      So, uhh, yeah.

      Reply

  8. 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:

    • Speed dips in the middle of a session.
    • “Soft” disconnection: meaning the adapter is able to recover.
    • “Hard” disconnection: requiring a USB reset of the device or unplug/plug it back.
    • Sub-par ~840 Gbps speed on 1GbE sub-net.

    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.

    Reply

    1. > 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).

      Reply

    2. 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.

      Reply

  9. 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.

    Reply

  10. 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

    Reply

  11. 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.

    Reply

      1. 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.

        Reply

        1. 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 command lspci | 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):

          1. build driver downloaded from https://www.realtek.com/en/component/zoo/category/network-interface-controllers-10-100-1000m-gigabit-ethernet-pci-express-software
          2. disable r8169 driver with command:
          3. sudo rmmod r8169
          4. 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>
          5. sudo bash -c 'echo "blacklist r8169" >> /etc/modprobe.d/blacklist-ethernet.conf'
          6. sudo reboot
          Reply

          1. And use command inxi -n to check driver of device ‘Realtek RTL8125 2.5GbE’ is r8125

Leave a Reply

Your email address will not be published. Required fields are marked *

Khadas VIM4 SBC
Khadas VIM4 SBC