Skip to content

Instantly share code, notes, and snippets.

@MadLittleMods

MadLittleMods/realtek-rtl-8153-driver-osx-info.md

Last active May 3, 2024 07:57
Show Gist options
  • Save MadLittleMods/3005bb13f7e7178e1eaa9f054cc547b0 to your computer and use it in GitHub Desktop.
Save MadLittleMods/3005bb13f7e7178e1eaa9f054cc547b0 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
realtek-rtl-8153-driver-osx-info.md

Realtek 8153

Download

Current version: 1.0.19 1.0.15 (as of 2018-12-10)

https://www.realtek.com/en/component/zoo/category/network-interface-controllers-10-100-1000m-gigabit-ethernet-usb-3-0-software

http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=13&PFid=56&Level=5&Conn=4&DownTypeID=3&GetDown=false

Realtek GBE USB

  • Gigabit ethernet
  • USB hub

Gather Info

  • 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

Reload OSX driver (kext)

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 and use the native driver

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

@halfbrilliant
Copy link

halfbrilliant commented May 2, 2024 •
edited

@zenczykowski Thanks very much for that, you’ve refined and clarified my understanding quite a bit. I’ve been about to pull the plug on a 2.5gbps USB-C adapter (I have no 2.5gbps hardware, well, apart from the other 2.5gbps dongle I bought that ended up using far too much CPU when there were lots of packets flying around to be acceptable). But then I saw someone say that the only “true” offloading one would be within the expensive kind of Thunderbolt dock (i.e. that has its own power supply and starts around £200/$200).

Are you saying that the Startech dongles (I prefer 2.5gbps because big number better, although I understand (oh how I understand) the overhead issues with USB, so unless a 5gbps dongle was Thunderbolt I’d steer clear for now) won’t cause a silly amount of CPU usage during a heavy torrenting session? If I may restate my wildest desires more flexibly/plainly: I don’t care whether it connects via USB or Thunderbolt, but a USB-C connection is preferred (but I do have adapters for both ways). I just don’t want the CPU usage to be more than e.g. watching a 4K 10bit video - I know that is being offloaded and that’s why the CPU usage is so low, but that’s kind of the point and - call me spoiled - that’s how I remember Ethernet connections behaving on my old Macs, my old PCs, etc. Certainly my 2012 MacBook Pro (non Retina, still going strong as my always on Synthogy Ivory 2 piano station) has a built in Ethernet port that does not use 30-40% CPU under heavy packet load (I am a dumb dumb, but something tells me it’s more the amount of packets rather than large packets, but something in my left shin is telling me that I just said a stupid thing)

Obviously the less it costs the better, but I would much much much rather pay twice as much for something and have efficiency and reliability.

Thank you very much for responding, I know I am by no means entitled to anybody’s assistance, and if it’s more appropriate to do this sort of thing over PM or another forum please let me know. Jungle is massive

@zenczykowski
Copy link

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.

Are you saying that the Startech dongles ... won’t cause a silly amount of CPU usage during a heavy torrenting session?

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment