Hacker News Reader

Comment by LinuxBender | Hacker News Reader

It's nice to see them giving this some attention. I hope they also look into the I225-V at the myriad of different negotiation bugs that change with each firmware revision on 2.5gb networks that also vary with different offloading features enabled/disabled including EEE. Each 2.5gb switch also exhibits different behavior which is probably not Intel's fault.

View on HN

When people say you need the third hardware revision to get functional performance, and it still doesn’t work, you should conclude it’s poorly designed. The fact that these chips were being sold with old hardware revisions also seems anti-consumer.

Agreed, Intel gave up and released the I226 because their I225 brand was so tarnished. I removed the I225 from my server after I noticed the driver crashing during heavy loads (Ubuntu 22.04). For USB I've been having success with the rtl8156bg from juplink.

I226 has the same bugs as i225, so I'm pretty sure it's just another hardware revision of the terrible i225 but renamed to try and trick consumers.

I got tired of fighting that NIC, and got a Realtek 2.5g one.

All my problems gone, life is good.

I would totally do that but I have a few mini-PC's that have the I225-V and I can't swap them out. I've used USB3.2->Ethernet dongles as work arounds until I could find a switch that was happy with it. Same with the latest Protectli firewalls, they also have the I225-V. For those I have to use ethtool to force a specific speed which is not ideal. I'm thinking mini-PC's are maybe a mistake in this generation of NICs.

Same boat here. Care to share what switch you ended up landing on? I'm still searching… :'(

They all have issues but the worst issues I ran into were on the TrendNet switches. The NIC's would start to get into carrier reset loops or sometimes would reset with no predictable pattern. I225-V + Trendnet seem to amplify each others bugs. Those switches also have problems with the I219-V. I threw those switches away.

The TP-Link and Netgear switches had the least issues for me in that I only had to force a particular speed to avoid sometimes negotiating at 100mb. I am not sure people will notice the negotiating bugs unless their family are heavy bandwidth users. I noticed it because of streaming and gaming at the same time plus I shut down my machines at night so I have a coin-flip chance of negotiating incorrectly every day.

Which mini PC's have the issue?

I do not have an all-inclusive list of which mini-PC's have the I225-V's. I have a few versions of the AMD Ryzen's and they all have them. The latest Protectli firewalls also mini-PC's have them. Several of the off-brand mini-PC's on Amazon have them. Some of the Intel NUCs may have them. If buying one of these online I suggest first posting a customer question about what NICs they have.

> AMD Ryzen

Damn. That's pretty much a requirement for any upcoming home lab gear here, so I'd better be careful about this aspect when researching.

Thanks. :)

I've had good experience with Realtek NICs too, not 2.5g yet but their 10/100/1000 models. I suspect that's because they use a far simpler design with not much in the way of fancy features[1]. They also tend to benchmark slower with higher CPU usage, but I'll take slightly slower but stable over fast but intermittent connectivity.

[1] Ironically, in this case the Intel has to have a fancy feature, intended for increasing performance, disabled in order to increase performance.

I've heard good things about Realtek's 2.5G nics, and bad things about Intel's; I've seen speculation that underlying cause is cross compatability between the two 2.5g specs that were merged into the standard and that most 2.5g switches use chips from companies that were behind the spec Intel was not behind.

For 1G realteks, I've had ok luck with them, but I do see some issues. I recall having some problem with them while running the Linux tree drivers, but I've since switched to all FreeBSD. With my current realtek NICs and FreeBSD 13.1, I have the choice of the kernel driver where sometimes the NIC will stop processing packets, and the NIC acknowledges reset, but doesn't actually immediately reset and sometimes processes old packets after resetting, resulting in wild writes and bad behavior. There's a vendor driver, which doesn't seem to get into that bad state, but it does enable ethernet PAUSE frames which are an abomination. The vendor driver is full of undocumented magic values and there's no public documentation on the NICs at all, so figuring out what to frob to make the NIC not get stuck, but not send out PAUSE frames would be an exercise in frustration, that I'm not willing to do.

Either way, the interrupt design is deficient: there's a shared interrupt for rx, tx and administration, and the status register doesn't really work right either --- it's possible for the host and device to disagree about what irqs were acknowleged and then things will get stuck (that doesn't seem to be the FreeBSD driver issue though; you can work around the stuck status communications by just assuming something probably happened aftet a few seconds, or checking for descriptor progess on rx and tx on any interrupt, etc). Having only a single interrupt means you can't meaningfully process incomming packets and finished outgoing descriptors in parallel which makes it hard to get full throughput in both directions simultaneously.

Anyway --- if they work for you, great. I'm going to avoid them where practical, and be careful with them elsewhere.

Same. From lore and experience, Intel is more stable than Realtek for 1G on Linux.

Intel managed to break some of their older consumer 1G NICs under Linux pretty reliably while adding support for newer NICs, and failed to fix them for a very long time.

At the end, Debian reverted Intel's patches and shipped a modified version which probably didn't enable some features on the newer NICs, but didn't break the older ones in the process.

It's ironic that the underdog Realtek has much more reliable cards which doesn't shudder under constant load and/or very long uptime scenarios. Realtek won't cut in server scenarios, but Intel's and Broadcom's server class NICs are completely different beasts when compared to Intel's consumer NICs, too.

Wish they had given some more attention to them while developing their drivers.

and there's no public documentation on the NICs at all

There is plenty if you search around, and they're one of the recommended NICs if you want to write an OS/driver because of that; they also show up in virtual form in various VM hosting software due to their simplicity:

https://wiki.osdev.org/RTL8139

https://wiki.osdev.org/RTL8169

https://www.iitg.ac.in/asahu/cs421/RealTek.pdf

Ok yes. I've done that actually. Pretty sure I used that pdf (or similar, although I think the one I used was marked confidential). But a pdf from 2002 tha is hosted from a university, not the vendor, isn't really up to the standard of public documentation. It wouldn't be so bad if their vendor drivers had comments or even sensible names for values when they frob the hardware, but it's just hex values with no explanations.

It's an OK NIC to work with hobby wise, although I quickly ran into issues with the status register, and I can only hope one day I'll get enough throughput to overwelm the nic. And then I'll move to an Intel nic of which I have several.

This is the classic Sutherland "wheel of reincarnation" cycle -- a function (commonly graphics acceleration or network connectivity) will be provided by the CPU, which is found to be a bottleneck so the function is offloaded to a dedicated device, which then becomes a bottleneck as the CPU receives more dedicated focus on performance improvement than some bespoke, single-purpose offload engine.

The Realtek NIC embedded in my Asus motherboard hits maybe 600mbps with a tailwind. It only has 1 receive queue and doesn't support interrupt coalescing. Junk.

> is probably not Intel's fault

consensus is Intel went down the shitter quality wise, just one example https://www.youtube.com/watch?v=DXNyHFOWx_k

Could be. Most of the folks I interacted with in the past have retired. I think I am just going to revert back to full tower PC's for anything I do, even firewalls and appliances so that I am not locked into what may be abandonware. I was hoping to use less power and take up less space with the mini-PC's but in hind-sight that may have been a mistake.

Fujitsu S920 seems to be a good option for a mini PC that is cheap and reliable. Not very fast, but has usb 3.0 and a x4 pcie slot. It has been very stable as my wifi access point. First heard about it on Wolfgang's channel.

Reply on news.ycombinator.com