Review: Cable Matters USB 2.5 Gigabit Ethernet adapter (posted 2021-03-03)
I think it was in 2016 that 2.5 and 5 Gigabit Ethernet was standardized. After a year or two the first USB to 5GE adapters started to appear at about €/$ 100 and about two years ago the first €/$ 50 2.5GE ones. Right now, there's a ton of USB 2.5GE adapters at good prices.
I got a Cable Matters one for € 31 off of Amazon. The adapter is a simple black rectangle with a short and relatively stiff (but not too short or too stiff) USB cable sticking out one end, and space for an RJ45 plug at the other end. There's an always-on blue light at the top of the adapter and a green link light and a yellow activity light where the Ethernet cable plugs in. The blue light is not annoyingly bright and the other two will probably face away from you in normal use. The USB cable is type A, but there's a USB-A to USB-C dongle attached to the cable in case you want to plug the adapter into a USB-C port.
The adapter supports 10, 100, 1000 and 2500 Mbps. Unlike even higher speeds (5GE and 10GE) 2.5GBASE-T (2.5GE) uses the same cat 5e wiring and the same 100 meter maximum cable length as 1000BASE-T (Gigabit Ethernet).
The system reports that the adapter requires a modest amount of power at 304 mA (1.5 W).
Cable Matters points towards a RealTek download page to get a driver. There is one for MacOS 10.9 - 10.15. I tried installing the driver on a laptop running MacOS 11 "Big Sur", and... that didn't work.
However, even without installing a driver, MacOS recognizes the adapter and the basic features work. These are the features reported by the ifconfig command:
supported media: media none media autoselect media 10baseT/UTP full-duplex media 100baseTX full-duplex media 1000baseT full-duplex
(I removed the word "mediaopt".)
There is no support for jumboframes or any type of offloading. And: no half duplex, not even for the original 10 Mbps mode. However, the adapter will autonegotiate 2500 Mbps mode, even though the OS reports 1000 Mbps. So you do get the extra speed, even without installing the driver. But it does look like the computer has trouble sleeping with the adapter plugged in.
Under MacOS 10.14 "Mojave", the driver installs without issue. After that, it turns out the adapter has a range of additional capabilities:
capabilities=2b<RXCSUM,TXCSUM,VLAN_HWTAGGING,TSO4> supported media: media none media autoselect media 10baseT/UTP half-duplex media 10baseT/UTP full-duplex media 10baseT/UTP full-duplex flow-control media 100baseTX half-duplex media 100baseTX full-duplex media 100baseTX full-duplex flow-control media 1000baseT full-duplex media 1000baseT full-duplex flow-control media 2500Base-T full-duplex media 2500Base-T full-duplex flow-control media 100baseTX full-duplex energy-efficient-ethernet media 100baseTX full-duplex flow-control energy-efficient-ethernet media 1000baseT full-duplex energy-efficient-ethernet media 1000baseT full-duplex flow-control energy-efficient-ethernet
So now the adapter can do half duplex at 10 and 100 Mbps, energy efficient Ethernet is supported at 100 and 1000 Mbps, as well as checksum offloading and TCP segmentation offloading for IPv4. Also, we can now enable jumboframes up to an MTU of 9194 at 1000 and 2500 Mbps. And wake-on-LAN works.
As my Ethernet switch tops out at 1000 Mbps, I connected the adapter to my Mac Mini with a direct cable to run some speed tests. I used iperf 3.1.4 for this, with the Mac Mini as the server and a 2016 MacBook Pro as the client. this means I only tested in one direction, which probably matters for the CPU usage I'll discuss below.
With or without the driver, iperf reports 280 megabytes per second (MB/s) and 2.35 Gbps for IPv4 and about a percent less at 277 MB/s and 2.32 Gbps for IPv6.
However, there is a significant difference in CPU usage for IPv4: the no driver 30-second iperf run used 0.8 s CPU time in user mode and 17.5 s for the system for a total of 18.3 s. So:
IPv4: 280 MB/s, 2.35 Gbps, 0.8 + 17.5 = 18.3 s
IPv6: 277 MB/s, 2.32 Gbps, 0.8 + 21.1 = 21.9 s
With the driver installed, that becomes:
IPv4: 280 MB/s, 2.35 Gbps, 1.3 + 9.3 = 10.6 s
IPv6: 277 MB/s, 2.32 Gbps, 0.7 + 19.7 = 20.3 s
So a 40% reduction in CPU use for IPv4 and only 7% for IPv6. This is probably because there is no TCP segmentation offloading for IPv6, only for IPv4. With TSO, the software delivers a very large packet to the Ethernet chip, which will then split that large packet into standard 1500-byte ones. And maybe without TSO6, the TCP checksum must also be calculated in software for IPv6 packets.
I retried my tests with larger packets, but only with the driver installed as this isn't supported without the driver. With a 9000-byte MTU, I got the following results:
IPv4: 270 MB/s, 2.27 Gbps, 1.7 + 8.5 = 10.2 s
IPv6: 294 MB/s, 2.47 Gbps, 0.7 + 5.9 = 6.6 s
So IPv6 got faster as expected, reaching 99% of the maximum line rate. IPv4, on the other hand, got slower, going from 94% efficiency to 91%. Turns out that something weird happens between the 8000- and 9000-byte maximum packet size, as these are the results for 8000 bytes:
IPv4: 284 MB/s, 2.38 Gbps, 1.1 + 5.3 = 6.4 s
IPv6: 294 MB/s, 2.47 Gbps, 0.7 + 5.7 = 6.4 s
IPv4 still isn't faster than without jumboframes, but at least it's not slower, and the CPU use is about a third for both IPv4 and IPv6.
This is a very nice USB Ethernet adapter. If you need a new USB Ethernet adapter, get this one or one like it, the Gigabit Ethernet era is coming to a close.