Current version: 1.0.19 1.0.15 (as of 2018-12-10)
Realtek GBE USB
- Gigabit ethernet
- USB hub
- Launch
System Preferences
->Network
- See
USB 10/100/1000 LAN
- https://i.imgur.com/Bm7D0Ld.png (mirror)
- https://i.imgur.com/wcMZFh8.png (mirror)
- Launch
System Information
(also known asSystem Profiler
) ->Hardware
->USB
- https://i.imgur.com/NJi9yC4.png (mirror)
- Launch
System Information
(also known asSystem Profiler
) ->Software
->Extensions
- https://i.imgur.com/64QCxxS.png (mirror)
- Launch a terminal/shell
ioreg -p IOUSB -w0
ioreg -p IOUSB -w0 -l
: For more info
+-o Root <class IORegistryEntry, id 0x100000100, retain 14>
+-o Root Hub Simulation Simulation@14000000 <class AppleUSBRootHubDevice, id 0x1000002fa, registered, matched, active, busy 0 (6 ms), retain 13>
+-o USB2.0 Hub @14100000 <class AppleUSBDevice, id 0x1000002fb, registered, matched, active, busy 0 (43 ms), retain 14>
+-o Apple Internal Keyboard / Trackpad@14400000 <class AppleUSBDevice, id 0x1000002ff, registered, matched, active, busy 0 (96 ms), retain 22>
+-o USB3.0 Hub @14500000 <class AppleUSBDevice, id 0x100000363, registered, matched, active, busy 0 (54 ms), retain 15>
| +-o USB 10/100/1000 LAN@14540000 <class AppleUSBDevice, id 0x100000418, registered, matched, active, busy 0 (73 ms), retain 18>
+-o Bluetooth USB Host Controller@14300000 <class AppleUSBDevice, id 0x1000003d8, registered, matched, active, busy 0 (58 ms), retain 24>
Terminal output snippet from `ioreg -p IOUSB -w0 -l`
+-o USB3.0 Hub @14500000 <class AppleUSBDevice, id 0x100000363, registered, matched, active, busy 0 (54 ms), retain 15>
| | {
| | "sessionID" = 2480892594
| | "iManufacturer" = 1
| | "bNumConfigurations" = 1
| | "idProduct" = 2066
| | "bcdDevice" = 37009
| | "Bus Power Available" = 900
| | "USB Address" = 5
| | "bMaxPacketSize0" = 9
| | "iProduct" = 2
| | "iSerialNumber" = 0
| | "bDeviceClass" = 9
| | "Built-In" = No
| | "locationID" = 340787200
| | "bDeviceSubClass" = 0
| | "bcdUSB" = 768
| | "USB Product Name" = "USB3.0 Hub "
| | "PortNum" = 5
| | "non-removable" = "no"
| | "IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"}
| | "bDeviceProtocol" = 3
| | "IOUserClientClass" = "IOUSBDeviceUserClientV2"
| | "IOPowerManagement" = {"DevicePowerState"=0,"CurrentPowerState"=3,"CapabilityFlags"=65536,"MaxPowerState"=4,"DriverPowerState"=3}
| | "Device Speed" = 3
| | "USB Vendor Name" = "VIA Labs, Inc. "
| | "idVendor" = 8457
| | "IOGeneralInterest" = "IOCommand is not serializable"
| | "IOClassNameOverride" = "IOUSBDevice"
| | }
| |
| +-o USB 10/100/1000 LAN@14540000 <class AppleUSBDevice, id 0x100000418, registered, matched, active, busy 0 (73 ms), retain 18>
| {
| "sessionID" = 3379212797
| "iManufacturer" = 1
| "bNumConfigurations" = 2
| "idProduct" = 33107
| "bcdDevice" = 12288
| "Bus Power Available" = 900
| "USB Address" = 8
| "bMaxPacketSize0" = 9
| "iProduct" = 2
| "iSerialNumber" = 3
| "bDeviceClass" = 0
| "Built-In" = No
| "locationID" = 341049344
| "bDeviceSubClass" = 0
| "bcdUSB" = 768
| "USB Product Name" = "USB 10/100/1000 LAN"
| "PortNum" = 4
| "non-removable" = "no"
| "IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"}
| "bDeviceProtocol" = 0
| "IOUserClientClass" = "IOUSBDeviceUserClientV2"
| "IOPowerManagement" = {"ChildrenPowerState"=4,"DevicePowerState"=0,"CurrentPowerState"=4,"CapabilityFlags"=32768,"MaxPowerState"=4,"DriverPowerState"=4}
| "Device Speed" = 3
| "USB Vendor Name" = "Realtek"
| "idVendor" = 3034
| "IOGeneralInterest" = "IOCommand is not serializable"
| "USB Serial Number" = "002427FE48F6"
| "IOClassNameOverride" = "IOUSBDevice"
| }
|
- Launch a terminal/shell
ifconfig
en4: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=2b<RXCSUM,TXCSUM,VLAN_HWTAGGING,TSO4>
ether 00:24:27:fe:48:f6
inet 192.168.1.135 netmask 0xffffff00 broadcast 192.168.1.255
media: autoselect (1000baseT <full-duplex,flow-control>)
status: active
The driver is located at
/System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/AppleRTL815X*.kext
/Library/Extensions/AppleRTL815X*.kext
Here are the namespaces:
com.realtek.driver.AppleRTL815XEthernet
com.realtek.driver.AppleRTL815XComposite
See http://osxdaily.com/2015/06/24/load-unload-kernel-extensions-mac-os-x/
With normal operation with only the network cable plugged in, I only see com.realtek.driver.AppleRTL815XEthernet
loaded.
# Unload
sudo kextunload /Library/Extensions/AppleRTL815XEthernet109.kext
sudo kextunload /Library/Extensions/AppleRTL815XComposite109.kext
# Load
sudo kextload /Library/Extensions/AppleRTL815XEthernet109.kext
sudo kextload /Library/Extensions/AppleRTL815XComposite109.kext
# Find if loaded
kextstat | grep com.realtek.driver.AppleRTL815XEthernet
kextstat | grep com.realtek.driver.AppleRTL815XComposite
Perhaps clear the Kernel cache
sudo rm -rf /System/Library/Caches/com.apple.kext.caches
I got a new USB ethernet adapter because the old one had lots of issues (hence the gist in the first place). But it still uses the same Realtek 8153 chip although am using the native driver though now, AppleUSBECM.kext
In terms of my previous issues, I remember that when I clicked the little lock in the browser to view the cert, it would crash my computer. But the disconnects that required a restart were the bigger issue. (personal reference link)
I'm currently running macOS Mojave 10.14
Perhaps first some background.
There's a lot of USB Ethernet dongles available on the market. This makes it seem like there's a lot of choice. This isn't actually really the case. In practice these dongles are very thin wrappers around a USB-Ethernet converter/controller chip. Basically you have a chip, you have build & connector quality and how well the case can get rid of any chip generated heat (mostly matters for >1gbps speeds) - that's pretty much it. The only component that really truly matters (for most intents and purposes) is the chip (and technically the firmware/eeprom on it). There's actually very few of these, especially if you're talking about >1gbps speeds. Stuff might have changed, but there used to be just a single aquantia (since bought by marvell) chip capable of 5gbps ethernet, and two chips (one from aquantia, one from realtek) capable of 2.5gbps ethernet. There's a bit more choice with 1gbps, and more of a smattering with 100mbps.
[though note there is some extra variability due to chip revisions, and the firmware and other programming on the eeprom]
The chip has two 'sides'. One is the ethernet side, this is what 'gigabit' in a gigabit usb ethernet dongle refers to: the chip is capable of supporting gigabit ethernet speeds (and note: gbps ethernet is full duplex: you can read and write a gigabit at the same time). But since these are converter chips, there's also the USB side, which also has a max speed. This speed is often lower than the ethernet speed. There are plenty of 'gigabit ethernet usb dongles' that are only USB2.0 (theoretical 480mbps half duplex, which in practice is much lower, USB2 protocol efficiency is pretty terrible). This is why it's not rare for a 'gigabit' usb dongle to only be able to do ~400 mbps. Or why the '5 gbps ethernet' dongles max out around 3.5gbps.
USB naming is an utter mess. The original USB3.0 (superspeed) can only do 5gbps at 8b10b coding, which gives a data rate of 4gbps, and protocol overhead cuts it down further. USB3.1 (technically USB3.1 Gen2 superspeed+) can do 10gbps on short (<1m ~3ft) cables - and this finally uses a decent coding: 128b132b, so it can actually do 9.7gbps data rate (protocol overhead will still cut it down a bit). Yeah: 10gbps usb3 is ~2.4x faster than 5gbps usb3... But, I'm not aware of any usb/ethernet converter chip that is actually superspeed+ capable.
Another thing worth pointing out: a USB3 cable carries USB3 signaling on different wires than USB2/USB1.1/USB1. This means you can have a cable (or connector) which works for USB3 but doesn't work for USB2 (or the reverse, or is flaky and works sometimes...). This is even worse with USB-C cables, where there's multiple possible paths, multiple connector orientations, and some cables cheap out and don't include the USB3 wires at all, etc. ie. you can somewhat theoretically end up with a USB-C to USB-C cable that only works in one of 8 orientations (which end of the cable goes into which device, plus orientation of both connectors)... You can also end up with similar problems with USB-C ports (half broken, only works in one orientation), or device/dongle attached USB cables...
Furthermore 'gigabit ethernet' is referring to the bit-rate on the wire, but there's some framing overhead, which means that at the standard (internet max) mtu of 1500 bytes, a normal ipv4/tcp stream can only fit 1500 - 20 ipv4 header - 20 tcp header - 12 tcp timestamp options = 1448 payload bytes. Additionally Ethernet will prefix this with an 8 byte preamble, 14 byte ethernet header, and postfix this with a 4 byte CRC and 12 byte interframe gap. This means 1448 payload requires transmitting 1538 bytes. This in turn means 'gigabit' can transfer 1'000'000'000 bits / 8 bits per byte / 1538 bytes per frame = ~81274 packet per second, at 1448 payload bytes per second, that's ~117685305 bytes/s or ~112.2 MiB/s (which is 112.2*8= 897.6 mebibits/s)
The main benefit of 2.5gbps dongles is that (a) it's more future proof (b) you're less likely to run into garbage, simply because there's a fair bit less choice and these are still mostly premium (the run on the bottom of the barrel hasn't quite happened yet). There are plenty of good 'just' gigabit USB3 dongles on the market that can do bidirectional full gigabit. But there are also tons of bad ones.... Unfortunately a lot of the otherwise good ones, use the realtek chip with no native arm mac driver, that ends up using the dreaded low-performance AppleUserECM driver (side note: the terribly low performance of this hardware agnostic driver is entirely Apple's fault, but I'm guessing they [like me] would just prefer everything moves over to NCM). It's my understanding that an NCM spec revision to add some offload capabilities (presumably checksum and tso) is in the works.
Another comment: a lot of USB controllers (the chip built in to the desktop or laptop) in general leave quite a bit to be desired. Many of them for example don't support scatter gather (meaning all data has to be in a linear memory buffer with no page fragmentation), or even if they do support it, they support it poorly enough, that it's still faster if you linearize all data first (by copying it on the cpu). These aren't fundamental limitations of the USB protocol, but more actual implementation details... Networking happens to be one of those cases where the native network packet size (1500) and the native USB3 packet size (1024 or multiples there of, like 16384) are a very poor match, and result in this being particularly problematic. This is basically why native PCI networking is so much better. You can somewhat fix this by increasing network mtu size - but that doesn't help with internet bound traffic.
I don't actually have the mac hardware to test this, but I would assume it'll be sufficient... Though do note it is still USB and not PCI (which is I believe what Thunderbolt adapters end up using) so you'll likely still have the linearization problem, and it's [presumably?] offload-less NCM rather than some checksum/tso offload capable native driver (note: tso can also mitigate some of the linearization/scatter gather problems...). Hard to say whether you'll consider this acceptable or not (I guess by it on Amazon, test it, report, and possibly return it?).
I'm not sure what native csum/tso capable usb3 >=gigabit ethernet dongle drivers an arm mac even has (both included by Apple, and whether any vendors actually provide native arm mac drivers). If you could find a dongle which uses such a native driver, you'd probably be happier (but I think Apple has been trying to prevent non-Apple kernel extensions, so it's possible such don't even exist any more??).
I do know on Linux we do have both the NCM generic driver and native drivers for these (r8156 I believe) dongles, but unfortunately I'm on vacation and left my pile of dongles at home so can't actually test the performance difference.
In general you are absolutely correct that large packets are easier to handle then small packets. Well, that's of course not true when phrased that way. The point is that a 'gigabit' is 81274 pps at 1500 mtu, but that same 'gigabit' can also deliver small packets. For example IPv4/TCP SYN will likely be not much larger then the ethernet minimum size of 46 bytes. This means you can get 1'000'000'000 / 8 / (8+14+46+4+12) which can give you 1'488'095 pps. So you have ~18.3 times more pps, and the packet is nowhere near 18 times cheaper to process: per packet processing overhead is huge (for example: firewall overhead is basically entirely per packet, as is figuring out which application socket a packet is bound for). Side note: small packets get no benefit from TSO (which is about offloading packet splitting to the nic, obviously no need for that if the packets are < mtu), and get virtually no benefit from checksum offload (which is mostly about checksumming the payload, of which there may be none). Perhaps to rephrase that: checksum offload makes the per-byte-of-payload overhead cheaper, but doesn't make per-packet overhead any better. TSO (and it's reverse on receive) actually reduces the number of packets one must send (or receive) and is thus a big win. On Linux (which I'm very familiar with) even for non-TSO capable hardware the stack jumps through hoops to basically do software TSO (so called GSO, and the reverse GRO) - this gets the majority of the benefit of less packets (in the firewall for example) without the need for hardware. I'm afraid I have absolutely no idea how optimized the network stack is on Apple. There's a reason that Linux dominates all sort of network/server environments...