Rui Carmo
The WP-UT5 wisdPi 5Gbps USB Ethernet Adapter
This is another review that has been quite some time in the making because I needed to get the right kind of additional hardware to do it justice.
There’s a lot going on in the home networking space–especially where it concerns moving beyond “just” gigabit networking. For starters, mini-PCs of all kinds are now (mostly) to shipping with 2.5GbE ports, and I recently reviewed a set of Sodola managed switches with 2.5GbE interfaces and 10GbE SFP slots.
Furthermore, I just got my hands on a Terramaster NAS with dual 10GbE, so things are indeed speeding up in consumer land.
But what can you do regarding upgrading machines like an older Mac mini? Well, that’s where USB Ethernet adapters come in–the WP-UT5 is a USB 3.2 adapter with the RTL8157 chipset that works with just about every computer I have, and that I have been testing (along with its PCI counterpart, the WP-NA5000) for a few months now.
Disclaimer: wisdPi sent me a WP-UT5 and a WP-NA5000 free of charge, and as usual this piece follows my review policy.
This post is going to focus on the USB-C adapter, since I’ve only barely tested the PCI card–the one PC I had with a free PCI slot is still effectively in a tiny compact case, and although I assembled everything outside the case to verify things worked I couldn’t keep it strewn about my workbench (I’ve been meaning to get a bigger case, but have other priorities).
Compatibility
First of all, let’s talk about compatibility. Since it uses USB 3.2, the adapter can tap into the full 20Gbps bandwidth of the USB 3.2 spec, but it will also work with older USB 3.0 ports (which are still pretty common on older machines), although most of the machines I have tested it on have USB-C ports.
Which reminds me–besides USB-C to USB-C you also get a USB-C to USB-A cable in the box, so you can plug it into just about anything:
Where it regards Ethernet cabling, it’s also worth saying I had zero issues with my Cat 5 installation (which, since it consists mostly of short runs, I already knew will support 10Gbps), and pretty much any cables run in the past ten years should be able to handle 5Gbps just fine.
The real question is, of course, how well it works with different operating systems.
OS Support
So far, the experience was completely plug and play. The first machine I tested the adapter on was my work Lenovo X1 Yoga, and Windows 11 automatically downloaded and installed the driver.
As to Macs, macOS Sequoia also worked fine (and has been working for many weeks now), the only caveat being that the Network Settings panel thinks the interface is 1GbE rather than 5 (even when plugged into a 10GbE SFP).
This is solely a UI issue since I can certainly get much more than that (in fact, pretty close to line speeds, and around 4 times faster SMB file transfers than with gigabit Ethernet), and I hope Apple will fix it in a future update.
In Linux, though, things are… different. I had a couple (pre-6 or pre-6.10) machines where the adapter was either incorrectly detected or just didn’t work, but it works fine under Fedora 40, and across the multiple ARM boards I’ve tried it worked the vast majority of times.
Most of the variation here is certainly due to the usual “mystery meat” kernels that ship with SBCs, but in general, all boards with Realtek adapters (like the CM3588) detected and activated the card on the first try (apparently re-using the same kernel driver), although, like on the Mac, the hardware reported line speed was different from what I knew was in use:
❯ dmesg
[ 5008.341772] usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
[ 5008.360372] usb 2-1: New USB device found, idVendor=0bda, idProduct=8157, bcdDevice=30.00
[ 5008.360406] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=7
[ 5008.360421] usb 2-1: Product: USB 5G Ethernet
[ 5008.360434] usb 2-1: Manufacturer: WisdPi
[ 5008.360448] usb 2-1: SerialNumber: 000334C8D6B103B9
[ 5008.432988] cdc_ncm 2-1:2.0: MAC-Address: 34:c8:d6:b1:03:b9
[ 5008.433029] cdc_ncm 2-1:2.0: setting rx_max = 16384
[ 5008.433233] cdc_ncm 2-1:2.0: setting tx_max = 16384
[ 5008.434502] cdc_ncm 2-1:2.0 eth2: register 'cdc_ncm' at usb-xhci-hcd.0.auto-1, CDC NCM (NO ZLP), 34:c8:d6:b1:03:b9
[ 5008.471894] usbcore: registered new interface driver cdc_wdm
[ 5008.475904] usbcore: registered new interface driver cdc_mbim
❯ lshw
...
*-network:4
description: Ethernet interface
physical id: f
bus info: usb@2:1
logical name: eth2
serial: 34:c8:d6:b1:03:b9
capabilities: ethernet physical
configuration: autonegotiation=off broadcast=yes driver=cdc_ncm driverversion=6.1.75-vendor-rk35xx duplex=half firmware=CDC NCM (NO ZLP) link=no multicast=yes port=twisted pair
❯ ethtool eth2
Settings for eth2:
Supported ports: [ ]
Supported link modes: Not reported
Supported pause frame use: No
Supports auto-negotiation: No
Supported FEC modes: Not reported
Advertised link modes: Not reported
Advertised pause frame use: No
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: 2500Mb/s
Duplex: Half
Auto-negotiation: off
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
MDI-X: Unknown
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
The only real issue I noticed is that some driver versions would fall over when doing auto negotiation with a 10GbE interface:
❯ ethtool ethtool -s eth2 autoneg off speed 5000 duplex full
netlink error: Operation not supported
❯ ethtool -s eth2 autoneg off speed 1000 duplex full
netlink error: Operation not supported
…and this is, well, OK–all things considered. I’ve gone through this kind of dance with just about every variation on Ethernet since 1Mbps coax, and a little bit of weirdness is to be expected with new chipsets.
Performance
Testing this was, as you might expect, somewhat non-trivial. Running iperf3 on two 2.5GbE SBCs plugged into my Sodola switches with the WP-UT5 hanging off a 10GbE SFP plugged into a third SBC worked (but mostly to demonstrate interoperability).
The real issue for me is that for a while I just didn’t have enough machines with faster network ports to test this properly.
I ended up dismantling rogueone, plugging in the WP-NA5000)onto the bare motherboard laying atop my cork desk mat (sadly, I didn’t take pictures of that setup), and confirmed I could do 4.3Gbps (using iperf3) between that and the WP-UT5 adapter plugged into one of my SBCs, but that was a single data point and wasn’t really tenable as a long term test setup.
I also briefly considered testing it on my DS 1019+ Synology NAS (which has slower dual 1GbE ports), but that requires installing a specific driver package and I frequently upgrade the OS on it, so I decided against that to avoid possible glitches.
(Without the driver, the NAS completely refused to detect it, of course.)
I able to plug the adapter to my Sodola switches without any issues (either to a 2.5GbE port or to a 10GbE SFP), but trying to saturate the interface without something else on the other side was tricky, and trying to do that with multiple 2.5GbE clients on the other end wasn’t really reliable.
So even though I have been using the adapter for a while on my Mac mini using it against the all-SSD ZFS NAS I recently setup, I wasn’t really getting past 2.5GbE–which is nice, but not earth-shattering.
But, again, a couple of weeks ago I got the TerraMaster F4-424 MAX, which actually has dual 10GbE. So once I got Proxmox running on it (post to come later) I did a little more testing–I was able to get 4.5 to 4.6Gbps sustained traffic with a direct connection to the WP-UT5 on my Mac, which is pretty great.
Thermals
Unlike the 10GbE SFPs I have been using on my Sodola switches (which can become painfully hot), the wisdPi Wp-UT5 ran only slightly warm–and that was only really noticeable when unplugging it from my Mac mini after a week’s worth of continuous use.
Conclusion
The WP-UT5 is a great way to quickly upgrade an older machine to 5GbE (especially a laptop), and the plug-and-play experience across Windows and macOS makes it a non-brainer (although I still hope Apple will fix the UI issue).
Linux users may encounter some quirks and variations in performance due to differing kernel support and configuration anomalies, but I think that won’t be a showstopper for most people–it’s more of an artifact of my particular little menagerie of ARM boards.
I expect to be able to put together a permanent, “new old” desktop machine with the WP-NA5000 soon (I just really need to get a roomier case), and I’ll be sure to post about that as well–including a bit more on VLAN support and perhaps even faster Ethernet switches… We’ll see.
