Comments on Nothing but bad experiences with Realtek Ethernet NICs

I appreciate this article, maybe it is my confirmation bias but it gives real-world examples of the issues with Realtek NICs which I've always expected. I bought an MSI B550A-pro (has RTL8111H) and immediately installed an Intel PCIe NIC because I knew I didn't want to bother with any Realtek on-board. Other motherboards with both brands of 2.5GbE were also riddled with problems and like you say AMD boards with Intel GbE are rare and expensive.

I have decided to change my PC case to a Fractal Torrent Compact and now realise that I won't be able to put the Intel PCIe NIC in the bottom slot anymore because I want to have fans installed there. So I've been running for 3 weeks on the RTL8111H with the Intel card removed, just to see how it goes.

To my surprise I have not seen any issues so far. I've used my PC (Win10) for several hours at a time daily and never seen it drop. I tested it by copying a 50GB file from my NAS and it kept 930Mbps+ with ~3% CPU usage (about 6 mins).

I guess I am one of the lucky ones?? I kind of hope so because if not I will need to get a different AM4 motherboard with Intel GbE NIC, kind of like unicorns...

Many thanks again for the article!

I've also had many issues with Realtek NICs. Unfortunately I've been spoiled by mainly using 3Com and intel NICs in the past so my initial reaction to network problems was it had to be a software or maybe overheating problem. Eventually I came to the inescapable conclusion that it was the Reaktek NIC hardware. Thank you for your article, it strongly reinforces my conclusion.

I have over 40 years experience writing software for real time embedded systems and if I had to guess what the problem is with the Realtek chipset I would say it is probably not the amount of RAM but the embedded interrupt hardware. I have seen other hardware unable to cope with asynchronous events such as the end of a byte being assembled and concurrent access by an external CPU of internal (to the peripheral chip) registers. Things such as "the status bit cannot be set" or "an interrupt cannot be generated" or "corrupted data is saved in the buffer"... Trust me, Ive seen this happen many many times. Consider the WD8250 UART in the early IBM PC. This had a bug in it that would cause a byte to be sent out multiple times if you poled the device too fast. If you accessed the device while it was trying to update it's internal registers, the update would fail and it would send the byte again.

There are situations in which the order in which registers are accessed is very important. Reading a register once "might sometimes" clear an interrupt and reading the same register later on in the same interrupt handler thread "might sometimes" give you a different result between the two readings!

Sometimes I think hardware engineers should be forced to do community service as software engineers so that they get a feel for all the hoops the rest of the world has to go through to actually use their hardware :-)