Messages

Hi, have a problem that bugs me for years, no solution found yet:

Two clients with Linux, same update status:

1. SLOW: Libretrend i7 with Coreboot, Realtek NIC

2. FAST: Old Dell Precision M6500 notebook with Intel NIC.

Problem: when downloading e.g. updates, the FAST ist 30-times faster than SLOW, see attached.

Same mirrors,RJ45 cables changed twice, both attached to the same switch. So no real explanation.

Yesterday I did some iperf between the two clients.

For UDP, it does not matter, which is server and whicch is client:

20260118145326,SLOW,FAST,45678,1,0.0-30.0,3935190,1048952,0.025,0,2677,0.000,0

20260118145446,FAST,SLOW,45678,1,0.0-30.0,3935190,1048950,-nan,0,-1,-0.000,0

But for TCP direction matters:

20260118144505,SLOW,FAST,45678,1,0.0-30.0,3533963328,941434163

20260118144740,FAST,SLOW,45678,1,0.0-30.1,1690173504,449722645

-------------------------

First thought: RJ45 in SLOW machine is Realtek. But I have Realtek in other machines with same linux, always maxing out the bandwith possible. So I don't think it'S simply Realtek.

Why only TCP makes a difference? Is there offloading and that doesn't work properly in the SLOW machine? Maybe due to Coreboot @soundboard?

Any ideas how this difference in TCP-speed might be explainable?

:-)

Based on your iperf results and the specific hardware combination (Realtek + Coreboot), this is a classic case of TCP Offloading or Interrupt Throttling issues common with Realtek drivers on Linux.
Here is an analysis and potential solutions:
1. The "TCP vs. UDP" Clue: Hardware Offloading
The fact that UDP works fine but TCP is slow strongly points to TCP Segmentation Offload (TSO) or Generic Segmentation Offload (GSO). Realtek chips often have buggy implementations of these features in their firmware/drivers.
When these are enabled, the NIC tries to process TCP packets itself to save CPU. If it fails, it leads to packet retransmissions and massive slowdowns.
The Fix: Disable offloading on the SLOW machine:
bash
sudo ethtool -K <interface_name> tso off gso off gro off
Use code with caution.

Try running your iperf test again after this.
2. Driver Conflict: r8169 (Kernel) vs. r8168 (Vendor)
Most Linux distros use the open-source r8169 driver by default. While improved, it still struggles with certain Realtek revisions, especially regarding Receive Side Scaling (RSS).
The Fix: Install the official Realtek driver (often found as r8168-dkms in your package manager):
Ubuntu/Debian: sudo apt install r8168-dkms
Arch: sudo pacman -S r8168
Note: You may need to blacklist the r8169 driver in /etc/modprobe.d/.
3. Coreboot & ASPM (Power Management)
Coreboot sometimes doesn't initialize PCIe Active State Power Management (ASPM) correctly. If the Realtek chip enters a low-power state (L1) during the tiny gaps between TCP acknowledgments, the latency spikes and throughput collapses.
The Fix: Disable ASPM via the kernel command line:
Edit /etc/default/grub.
Add pcie_aspm=off to GRUB_CMDLINE_LINUX_DEFAULT.
Update grub (sudo update-grub) and reboot.
4. Energy Efficient Ethernet (EEE)
Realtek NICS often have "Green Ethernet" (EEE) enabled. This can cause synchronization issues with certain switches, leading to the 30x speed difference you see.
The Fix: Disable EEE:
bash
sudo ethtool --set-eee <interface_name> eee off
Use code with caution.

Why the Dell (Intel NIC) is faster:
Intel NICs (like the one in your M6500) have superior hardware-level buffers and much more mature Linux drivers. They handle TCP window scaling and offloading far more gracefully than Realtek chips, which rely heavily on driver-side workarounds.
Recommended sequence for troubleshooting:
Test 1: Disable TSO/GSO with ethtool (Immediate effect, no reboot).
Test 2: Disable EEE.
Test 3: Switch from r8169 to r8168 driver.
Test 4: Disable pcie_aspm in GRUB.

hope can help you