I recently got a new Asus AMD B550-PLUS mainboard. It has a built-in Realtek PCIe 2,5-gigabit (RTL8125B) network interface controllers (NIC). As is often the case with Realtek NICs, it has been quite unreliable and is plagued with intermittent issues.
The NIC will randomly stop working after a few hours. It’s working fine according to the network status indicator and the networking troubleshooter in Windows. However, no traffic is getting either in or out of the NIC. Eventually, programs waiting on networking eventually time out and begin displaying error messages.
Neither disabling and reenabling the NIC in the Device Manager nor rebooting the computer fixes the problem. It needed a full power cycle before it would start working again; literally turning the computer off and on again.
In addition to the random failures, it would also stop working after the computer resumed from being suspended to memory (sleep mode). Notably, suspending to disk (hibernation) wasn’t a problem for it. It’s quite common for hardware to struggle when resuming the session after hibernating, but this wasn’t the case here. This is likely because hibernation involves completely powering down the system.
I thought it might be related to the NIC’s power-saving modes. The driver has half a dozen settings, and I tried various configurations for it and the computer’s PCIe power management. The power tuning didn’t make any difference.
Windows Update was quite happy with the Microsoft-supplied driver version 9.001.0410.2015 (released on 2015-04-10). The Realtek website supplied a much more recent driver version 10.50.511.2021 (released on 2021-05-11).
The newer driver mostly resolved the issue related to sleep and resume. The NIC now works when resuming from sleep, but it operates at a reduced speed for the first couple of minutes. Online network speed measurement tests confirm that the NIC is significantly slower than my internet connection while this is happening. After about three minutes, the NIC fully recovers and can operate at its normal fast speed again.
The NIC still randomly fails every couple of hours, though. It sometimes recovers on its own after some tens of minutes, but it’s not doing so consistently. Disabling and reenabling the NIC in Windows Device Manager also restores its functionality. That is at least is an improvement over the older driver.
The NIC also has problems running on the same hardware under Linux. The NIC randomly fails after a couple of hours, or the driver fails to load during start-up. Unloading and reloading its kernel module brings it back to life. This is no way to live, though.
Realtek markets the RTL8125 as a “gaming NIC.” I’m not sure what that entails, though. It has no more than the normal number of blinking lights! In a press release, Realtek claims it’s supposed to come with some sort of software for automated quality-of-service (QoS) network packet-prioritization “for gaming traffic.” It’s unclear if this is provided by some yet-to-be-released stand-alone software, the NIC driver, or is built into the firmware. Either way, this claim is so vague that it’s impossible to verify.
I’ve only ever had bad experiences with Realtek NICs going back over a decade. The NICs will randomly stop working and require some sort of manual intervention to recover. They’re particularly troublesome under FreeBSD and Linux, but they haven’t been much better under Windows.
For example, I’ve also got two other mainboards with different onboard Realtek NIC models. They’re hard to avoid. Almost all mainboards for AMD processor sockets come with a Realtek NIC. You can get some with Intel NICs, but they’re few and come at a significant premium. Realtek NICs are the price you pay to be an AMD customer.
My home theater computer (HTPC) is an ASRock DeskMini X300 with a Realtek RTL8111H NIC. It’s primarily used for online video streaming, where buffering mostly hides the fact that the NIC periodically resets. The stream sometimes stalls as it catches up with the buffering before the driver has reset and restored networking.
I’d like to replace the Realtek NIC with an Intel NIC. However, it’s a compact barebones system with no room for a PCIe expansion card. I could get a USB NIC, but those almost exclusively contain Realtek NICs. There are also some Ethernet–USB dongles on the market with NICs from ASIX Electronics. I’ve no experience with ASIX NICs, but I’d prefer to give those a try before any more Realtek products.
Unfortunately, most Ethernet–USB dongles don’t advertise what NIC is inside. Realtek is by far the most common option. I don’t intend to buy a load of generic unmarked dongles and hope to get one ASIX model in the mix.
Update (): A quick aside: Any USB–Ethernet dongle labeled as compatible with the Nintendo Switch should be an ASIX NIC. The Switch doesn’t come with Realtek drivers, but its operating system does include ASIX drivers.
My last Realtek NIC is an RTL8111H installed on an ASUS Prime X570-P. This has been my primary Linux workstation for the last few years. The NIC randomly disconnects about six times a day under Linux, and maybe three times under Windows. On Windows, I need to reboot to get it back up and running. On Linux, I need to unload and reload its kernel module to get it functional again.
The RTL8111H NIC also stops working after receiving a few megabits of UDP traffic, e.g. peer-to-peer protocol data. The UDP problem manifests under both Linux and Windows. Driver unreliability under heavy UDP traffic has also been noted by other customers of the 2,5 gigabit RTL8125B NIC. I haven’t been able to reproduce the problem with that NIC, although I can reliably trigger it with the older RTL8111H NIC.
So, I’m obviously not using the Realtek NIC on that computer. I’ve installed an Intel NIC on a PCIe expansion card to take its place. I haven’t had any Ethernet networking issues with it whatsoever.
I’ll replace the newer RTL8125B NIC on the Asus B550-PLUS with another Intel NIC on a PCIe card. It would be nice to play with the 2,5-gigabit capabilities of the Realtek NIC. However, there simply aren’t any reasonably priced consumer-grade 2,5-gigabit switches on the market yet. Intel does have a few PCIe 2,5-gigabit NICs, but I haven’t decided if it’s worth the price premium over a one-gigabit card.
That’s just my current hardware, however. In 2015, I bought a small form-factor barebone computer with two built-in Realtek NICs for use with the then recently-announced OPNsense router operating system. OPNsense is based on FreeBSD and the Realtek drivers were incredibly unstable and regularly lost track of and dropped tens of percentages of packets.
Frustrated, with the Realtek drivers, I tried salvaging the hardware with IPFire: a Linux-based router. IPFire improved the Ethernet driver situation, but the NICs would still regularly stop responding and needed to be reset. The hardware was too unreliable to use as a network router, and I abandoned it in favor of another mainboard with an Intel NIC.
I remember struggling with other Realtek NICs on Windows and other operating systems every time I’ve encountered them in the last two decades. The solution has always been to replace them with more reliable and well-supported Intel NICs.
My recommendation is clear: Avoid Realtek network equipment. Pay the premium for an Intel NIC when possible. Don’t waste your time; get a replacement Intel NIC PCIe expansion card at the first sign of networking trouble. Realtek is cheaper for a reason.
So, what’s that reason? Why are Realtek NICs so unreliable and troublesome compared to Intel NICs? There are plenty of forum threads, mailing lists posts, and other online activites dedicated to various problems with Realtek hardware.
This is hard to authoritatively answer without spending months reviewing the hardware, drivers, and how they interact with the rest of the system. An anonymous contributor to the LinuxReviews wiki has a good theory:
Wired Realtek network cards tend to have very little RAM compared to network cards from Intel and Qualcomm. Even 10 year old Intel cards have 10 times the amount of RAM Realtek cards have. […] The lack of memory on Realtek products makes a difference for both stability and CPU interrupt use.
This observation matches my own. Less memory means smaller network traffic buffers, which in turn means the processor needs to spend more time checking in on the NIC.
A few months ago, I encountered a Kernel bug where two computers would lock up during a tangentially networked operation. The system would enter a state where the processor had a pending queue of system interrupts, but it would no longer process any of them. It only took a few minutes after boot before the system would lock up.
One of the systems used an Intel NIC. It also had an unused and unconnected Realtek NIC on the mainboard. After disabling the Realtek NIC in BIOS, it would take 30–40 minutes before that system would lock up. I then disabled the other system’s Realtek NIC and hooked it up with a Wi-Fi NIC instead. That set-up gave me two systems that took 30–40 minutes to crash instead of a mere minute or two.
The Realtek NICs generate a lot of interrupts, and the system’s interrupt handlers would be exhausted much faster with them enabled. The additional time gave me enough time to troubleshoot, experiment, and identify the underlying issue. I was then able to get an idea of where the fault was and could deploy a workaround for the issue. (It was some weird interaction between multidisk, LUKS disk encryption, and the BtrFS file system under heavy load.)
The Realtek driver on Windows and Linux both have settings for interrupt moderation, and other advanced settings. However, I don’t want to become a network wizard. I want my Ethernet NICs to be plug-and-play! That’s not the experience I’ve had with Realtek hardware.