N150 Mini PC, RTL8153, AX88179 and RTL8256BG - USB Ethernet adaptor experiences

[dogshome]

Hi All, These are the results I've had with the USB3 Ethernet adaptors listed in the title. N150 Acemagic Vista V1. I used the appropriate RTL and AX plug-ins.

RTL8153. Reaches virtually the available ~900Mbps download and upload available on my fibre. crashes occasionally under load. Fail!
AX88179. Limited to 250Mbps, but reliable. Fail!
RTL8256BG. Reaches the available bandwidth. Seems reliable depite my attempts to break it with speed test, Teams etc. Win!

With various packages like a blocklist in Unbound, Crowdsec and Intrusion Protection turned on, the most CPU useage I see is 20%. Memory, far less than 1G. My reason for switching from my recent TP-Link AX73 device is mainly because their firewall setting is now an android-controlled paid app. So I have that set up as an AP with an RE705 extender located in the other end of the house. That gives me reliable +-800Mbps over wifi(6) tapped into the extenders Gigabit port.


I hope this is of use to others.

[nero355]

Thank you for testing and reporting your findings but IMHO any kind of USB Networking on your OPNsense is simply wrong and not something you want to use for a long time : Any kind of (temporary) High CPU LOAD = The whole USB Bus starts tripping!

But you can keep them and use them in case any of your Clients suddenly has a NIC gone bad/defect :)

[dogshome]

Thanks for the rapid feedback. I saw several warnings about this online. However, I had the hardware laying about (apart from the 8256) which didn't stand me for much money.

Getting a dual NIC X64 PC etc with a half decent CPU in it would be a bigger investment. I have some DDR 3 laying about somewhere though, which would help a lot these days.
 

If it all goes die-down (geddit) or otherwise, I'll feed back.

[drosophila]

I only consider a NIC reliable when it
1) succeeds an iperf3 -P4 (P4 is important to stress SMP and get max throughput on slower CPUs) for at least 10 minutes, once as sender and receiver AND
2) succeeds in not locking up with an iperf3 -P4 --bidir (--bidir is the kill-switch for NICs/drivers). It may slow down on either direction, but it must not lock up or crash even once during the 10 minute test run.

This is for SOHO use. For serious business use anything less than sustained full speed in both directions with --bidir is not acceptable.

[dogshome]

Hi @drosophila - I am, of course, only playing at this :-) That test software looks like the equivalent of an engine dyno.

However, it's been up for 3 days now, happily accepted VPN and various dodgy test websites, although the IPN slowed some elements on the pages down, which I expected. Teams on my work machine and their VPN also good. Bit-torrent also happy, plus my wife's PC, various Amazon and Android devices and the TV which likes to call its friends.

The USB adaptor might well produce a melt-down at full load for extended periods, but cruising around town, out on the motorway or overtaking, it seems good.


You've made me curious though. I'll probably try iperf via an SBC on Linux to one of the listed servers and see what happens. Windows networking always seems a bit 'touchy' to me.

[drosophila]

I'll probably try iperf via an SBC on Linux to one of the listed servers and see what happens. Windows networking always seems a bit 'touchy' to me.

WRT NIC drivers and stability, Windows should be OK because up until recently, no vendor could afford to have drivers that don't work perfectly with Windows. With the slow shift towards Linux, this may change if it continues. What MS does to network management itself is another story of course.

Anyway, yes, I view the bandwidth test sites as some lightweight testing, especially the browser-based ones. Whenever I use iperf3 (there are different versions that aren't compatible), the first few tests are for stability, and I run the server on the DUT. The extra CPU load and stack activity is welcome in this case to better simulate real-world scenarios. For throughput testing, the docs recommend to use another server so that only the traffic passes through the DUT. That will then test both NICs in the DUT, so this typically is the last test I do after verifying each NIC individually.

Oh, obviously iperf3 -P4 --bidir also stress tests the NIC / driver in the initiating system as well, so if that one is flaky, that may lock up as well. :)