I recently noticed that Pi 4 integrated NIC caused a lot of troubles (first packets loss then following ones transmitted fine) compared to others NIC.
The issue is due to "EEE", some green washing technology used to save some milliwatts, decreasing the stability of the link. Most of the time, "EEE" works fine however on all my Pi 4 it's causing troubles to me.
Disabling:
It can be disabled by playing ethtool --set-eee eth0 eee off - on OpenWrt, just add it to /etc/rc.local (so it's disabled at every boot).
On my "ONT" (GPON converter fiber <-> ethernet) it's disabled by default, which makes me think I'm not the only one to think this should be disabled on things like routers.
Checking: ethtool --show-eee eth0 can be used to see whether it's active or not (and to check if disabling was successful)
It's a Pi 4 problem so I created a thread on their forum https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=305820 but as it's also affecting OpenWrt, so I believe it's useful to let people know about the issue. Not sure if this issue can be corrected by firmware or if it's an hardware poor performance of the Pi 4.
EEE is not "some green washing technology", but saves real money (via electricity). A single 1000BASE-T port needs around 1.5 watt to operate, regardless of the question if anything is connected or if the attached device is powered on. Dropping back to 100BASE-T in these cases (nothing connected, client powered off or in deep sleep (WoL)) reduces the per-port power consumption tp 0.1-0.3 watts. Multiply this with 4, 5, 8, 10, 16, 24, 28, 48 ports of common ethernet switches and 24/7 operations (you might power-off your clients over night, but switches often remain on all day) and you get very tangible power savings (I do still own first generation 1000BASE-T switches that don't offer EEE, they were running hot, needed heavy PSUs and were using way too much power). A device sold over the last 10 years really ought to cooperate with EEE without throwing the towel (even if it can't do it itself, at least it mustn't break if the other end uses it), otherwise it's just plain defective.
About this is funny how consumer router disable see for instability...
So I can't understand...
The switch needs to pass some certification to support EEE and then is disabled? Can't understand how something is certified and the cause stability perf. They disable that to boost perf?
Yes I'm may be exaggerating a little bit when using the term "green washing" about EEE
EEE is doing super fine with all of my devices apart from Raspberry Pi 4
BTW...unless something has changed...EEE (802.3az) is not enabled by default in OpenWrt...I've written about it...especially when it really caused me an issue when enabled thru my whole Layer 2 network. See:
This issue hit me with my CM4 lite installed in a dfrobot cm4 router dual gigabit board - eth0 would drop the link and then slow down to 100Mbps when connected to a gigabit port.
Occurring on both 21.02-rc3 and 21.02-rc4. I updated the rpi-eeprom to the 7 July 21 version trying to fix it, no difference.
There is a kernel message during boot that says
bcmgenet fd580000.ethernet: failed to get enet-eee clock
The glitch occurs intermittently and infrequently, but sometimes multiple times in a few minutes. Usually during large transfers. Connection is dropped and takes a while to re-establish. Sometimes the gigabit link comes back up fine, other times the port drops back to 100Mbps, if it slows down the only way to get it back to gigabit speed is to disconnect and reconnect the cable. I have tested multiple cables and switches and repeated the issue. I have removed and re-attached the CM4 from the router board. I am using the official Pi power supply.
My guess is the EEE function isn't synced properly as it can't get the clock - so the port loses synchronisation with the switch, misses enough packets or whatever for the other end to drop the connection.
Once I disabled eee using ethtool I have not had a single glitch despite quite a bit of testing by uploading and downloading through the device.
