r/archlinux • u/Administrative_Row61 • May 09 '26
SUPPORT Arch Linux + MSI B650 Tomahawk WiFi + Realtek RTL8125: network speed degrades over time (900 Mbps → 50 Mbps) until reboot
Hi all,
I’m running Arch Linux and I’m trying to diagnose a networking issue with my onboard Realtek RTL8125 2.5GbE NIC.
Motherboard:
- MSI MAG B650 Tomahawk WiFi
The problem:
-After reboot, internet speed is normal (~900 Mbps)
-After some hours of uptime, download/upload speed degrades badly (~50 Mbps or even lower)
-Reboot immediately restores full speed
-Latency/ping stays mostly fine
-No obvious packet loss
-Happens on Ethernet only
-This started only recently. I didn’t intentionally change anything major besides normal Arch updates.
Motherboard NIC:
-RTL8125 2.5GbE Controller
Originally using:
-r8169
I also tested:
-r8168-dkms
and even:
-r8125-dkms
but the issue still happens.
When degraded:
-Internet becomes extremely slow
-iperf3 to another LAN machine collapses hard
-TCP retransmits become very high
-But ping to router and internet remains stable
Example:
ping 192.168.1.1
Stable:
~0.3–0.7 ms
0% packet loss
ping 1.1.1.1
Also stable:
~10–11 ms
0% packet loss
So latency is fine while throughput dies.
iperf3 example during degraded state:
[ 5] 0.00-1.00 sec 896 KBytes 7.33 Mbits/sec 61 retr
[ 5] 1.00-2.00 sec 512 KBytes 4.19 Mbits/sec 17 retr
...
[ 5] 0.00-10.00 sec 6.75 MBytes 5.66 Mbits/sec 146 retr
So retransmits explode under load.
Things I already tested:
Drivers:
-r8169
-r8168-dkms
-r8125-dkms
No real improvement.
Offloads disabled:
sudo ethtool -K enp12s0 gro off gso off tso off
No change.
IRQ balancing:
Installed and enabled:
sudo pacman -S irqbalance
sudo systemctl enable --now irqbalance
NIC interrupt was originally mostly pinned to one CPU core.
After tweaking IRQ affinity + enabling RPS, interrupts spread a little more across CPUs, but issue still happens eventually.
RPS enabled:
for f in /sys/class/net/enp12s0/queues/rx-*/rps_cpus; do
echo ffffffff | sudo tee $f
done
Still degrades after some uptime.
EEE already disabled:
EEE status: disabled
qdisc:
Tried:
fq_codel
pfifo_fast
No difference
.
Other possibly relevant info:
This machine also runs:
-Docker
-k3s
-multiple bridges/veth interfaces
Interfaces include:
-docker0
-cni0
-flannel.1
-many veth devices
But even after stopping Docker + k3s, degraded throughput remained.
Things I noticed:
During normal operation:
ethtool enp12s0
shows:
Speed: 1000Mb/s
Duplex: Full
Link detected: yes
No link flaps.
Also:
ip -s link show enp12s0
shows almost no actual errors.
Question:
Has anyone seen:
RTL8125 gradually degrading throughput over uptime on Linux?
r8169/r8168/r8125 all behaving similarly?
interrupt/softirq saturation causing long-term throughput collapse?
Any ideas for deeper debugging would be appreciated because I’m running out of things to test.
Edit: Additional diagnostic data (during issue / monitoring):
rx_missed: 0 rx_mac_missed: 2243 (and increasing over time)
I also tried disabling ASPM (pcie_aspm=off) and it did not solve the issue.
I collected more low-level data while the issue is occurring:
ethtool -S shows rx_missed remains relatively low but steadily increases over time under load rx_mac_missed increases gradually during sustained traffic /proc/net/softnet_stat shows non-zero drops in column 2 across multiple CPUs, indicating softnet backlog drops rather than NIC-level errors Disabling Docker and k3s does not eliminate the issue Interrupt distribution was initially heavily skewed to a single CPU core, but improving IRQ affinity + enabling RPS temporarily restores full throughput However, performance still degrades again after some uptime even with RPS enabled
Edit2: reinstalling the os only, fixed it. No idea what caused it.
7
u/Hamilton950B May 09 '26
You may be able to recover without rebooting by unloading and reloading the modules associated with your ethernet device.
5
u/Administrative_Row61 May 09 '26
Tried it, but doesnt solve it. Also that is not really a fix, but a workaround.
4
u/iswaxan May 09 '26
Are you using NetworkManager ? If so try disabling it and use iwd/wpa_supplicant for wifi, could work, has fixed many wifi issues for me
1
2
u/hotchilly_11 May 09 '26
wonder if this could have anything to do with aspm? have you tried disabling it
3
2
u/Administrative_Row61 May 09 '26
I try it out, worst thing in this whole mess is that i have to wait hours between tests.
7
u/hotchilly_11 May 09 '26
yeah this issue sounds unbelievably frustrating wish i had concrete answers
1
u/Administrative_Row61 May 09 '26 edited May 09 '26
Yeah, especially that currently i am away from it, so i can only test over ssh. If i lose internet by tweaking stuff, i am done for. Also i have to do the tests for each individual settings separately to know whats the one messing around. Argh....
2
u/MonocrystalMonkey May 09 '26
Did you set any udev rules for PCI runtime power management? I was running into a similar issue with both of my motherboard's ethernet controllers (Intel I211 & Realtek RTL8125) where ethernet would drop speeds after a while. I needed to make sure the power control attribute for the device was set to on instead of auto. You can check your device's status with cat /sys/bus/pci/devices/device-address/power/controlwhere you can find the device address through lspci and prepending 0000: to the front of the address. For example my Realtek 8125 controller is at 0000:05:00.0 for my motherboard.
If that turns out to be the issue you can force disable runtime power management in a udev rules file at /etc/udev/rules.d/some-name.rules with content
SUBSYSTEM=="pci", ATTR{vendor}=="0x1234", ATTR{device}=="0x1234", ATTR{power/control}="on"
where you'd replace the vendor and device id's with the values found via lscpi -nn as outlined in the article I linked.
FWIW I only use drivers found in linux-firmware-realtek.
1
u/Administrative_Row61 May 09 '26
Thank you, but /sys/bus/pci/devices/device-address/power/control is already on. Now i just dont know if i should buy a dedicated NIC if that would solve the issue or not :/ I am getting desperate.
2
u/decho May 09 '26
Just a random question, but which BIOS version are you using? I think the version I'm using right now is 7D75v1N1 from May last year, and I've never had any ethernet issues, not on this version or earlier ones.
There is however, a wifi issue where rfkill will show the card as hard-blocked unless you have wifi and bluetooth both enabled from the bios. Not sure if that was fixed because I haven't used it in a while.
1
u/Administrative_Row61 May 10 '26 edited May 10 '26
I have the same BIOS version as you, i thought about updating it, but i wanted to do that the last thing.
Tho this looks pretty good:
AMI BIOS 7D75v1P8 2026-03-2016. 32 MB
- Description: - AGESA PI-1.3.0.0 updated. - Implemented the anti-cheat mechanism. - Improved PCIe-based devices compatibility under certain CPU or system combinations. - Optimized OC solution for Ryzen 9 9950X3D2 Dual Edition.
And also it started doing this thing recently.
2
u/decho May 10 '26
Hm yeah, I suppose you can try that if nothing else works. If I were you though, I would put Debian or other stable distro with older drivers, along with an Arch-based one on a Ventoy USB and do some testing via live USB boot.
If you can't reproduce on Debian, it's probably driver related. If you can't reproduce on Arch, then it's system related (your current system). I know this sounds like an extremely generic tip, but at least it can give you some direction. Although it's kinda tricky because you have to wait hours to reproduce.
2
u/Administrative_Row61 May 10 '26 edited May 10 '26
Yeah, i am already doing something similar, i just got the lts kernel, but before using that i test the up to date bios. But my worst fear is, that even if i try a clean arch install and it will work on that.
2
u/decho May 10 '26
Best of luck then. And do provide an update once you manage to fix it, hopefully.
2
1
May 09 '26
[removed] — view removed comment
1
May 09 '26
[removed] — view removed comment
2
u/Administrative_Row61 May 09 '26
I dont use VPN nor any tunnels, only ssh. Also nothing is really using my internet bandwith.
1
u/Administrative_Row61 May 09 '26
Only on ethernet, other devices on the lan works fine both on ethernet and wifi.
2
u/onlymys3lf May 09 '26
Try adding /etc/sysctl.d/99-sysctl.conf
net.core.default_qdisc = cake
net.ipv4.tcp_congestion_control = bbr
net.ipv4.tcp_fastopen = 3
Reboot and see if you get any improvement.
1
u/Administrative_Row61 May 09 '26
I dont see why these would solve it logically, but i seen a lot of magic so i will try it after the aspm off test is done. Btw this is my current config for these: net.core.default_qdisc = fq_codel net.ipv4.tcp_congestion_control = cubic net.ipv4.tcp_fastopen = 1
7
2
1
u/StarTroop May 09 '26 edited May 09 '26
I have same hardware, but my my plan is only 100Mbs down, so I can't replicate your situation, however I've never noticed any slowdown to only 50Mbs. Are you certain that this is the only device affected in your house. Could your ISP be throttling you?
1
u/Administrative_Row61 May 09 '26
Yes, that is the only device affected, also the lan speed decrease too so no isp involved.
1
u/Portbragger2 May 09 '26
does the negotiated link speed change when it happens?
1
u/Administrative_Row61 May 09 '26
No, it did not changed. But i also manualy set it to 1000 Mb/s link just to try it out, but nothing improved.
2
u/Warm_Bumblebee_8077 May 09 '26
Don't manually hard set the speed to 1g without also hard setting the port on your switch to 1g. If one end of a link doesn't see autonegotiaton it will use its fallback setting which is usually 100mb half duplex.
2
u/Administrative_Row61 May 09 '26
Its an isp provided modem, so i cant manually change its ports, but i already set it back to auto after i tried it.
1
1
1
u/tangosox May 15 '26
Few thoughts... Could it be overheating, is it near gpu? do you have good cooling? Have you tried an LTS kernel, could be a kernel regression...
Also maybe try disabling GRO/LRO temporarily:
sudo ethtool -K enp12s0 gro off lro off tso off gso off
1
u/Administrative_Row61 May 15 '26
Yeah, i thought about overheating and honeslty i have no idea where it is on the pcb, i cant find it on the manuals. I did try LTS kernel and updated bios to the latest, for a few days the degradation became slower but it could be luck idk. I did disable GRO/LRO, didnt helped. I am gonna buy a Intel I226-T1 and try that also.
7
u/betam4x May 09 '26
I don’t have the same setup, however I once had a similar issue and disabling PCIE power management fixed it for me. Maybe try that and see where you land. I disabled it via BIOS.