Severe Packet Loss on Beelink SER5 (Ryzen 7 6800H) with 2.5GbE (Proxmox 9.0.11)

E

elpigeondindo

Member
Jul 27, 2023
9
0
6
Hello everyone,

I'm seeking assistance with a major network stability issue on my new Proxmox host. I have tried several known software fixes without success, and I suspect a deeper hardware/driver incompatibility at 2.5 Gbps.

System & Problem Details​

  • Host Hardware: Beelink SER5 Mini PC
  • CPU: AMD Ryzen 7 6800H
  • NIC (Network Card): Realtek RTL8125 2.5GbE Controller (Confirmed via lspci)
  • OS: Proxmox VE 9.0.11 (Kernel 6.5.11-4-pve / or similar 6.x)
  • Connection: Wired to a 2.5 Gbps switch (currently a Yuanley YS25-0801, but the issue persists with others).
When the link is established at 2.5 Gbps, I experience severe packet loss (approx 75) and extremely high, erratic latency (up to 1600 ms) on PING tests. The connection is practically unusable.

The only stable workaround I have found is to force the network connection to 1000 Mbps (1 Gbps) using the following ethtool command:
Code: 
/usr/sbin/ethtool -s enp2s0 autoneg on advertise 0x025
The network becomes perfectly stable when I force the link speed to 1 Gbps.

Troubleshooting Steps Already Taken​

  1. Driver Change: Attempted to blacklist the default r8169 kernel module and successfully installed and forced the proprietary r8125 DKMS driver. Result: The high latency/packet loss issue persisted. (I have since reverted/checked, and the system is back on the generic r8169 driver based on the logs below, but the issue remained on r8125 too).
  2. Offloading Disabled: I used ethtool to disable all hardware offloading features, which often causes this issue with Realtek chips:
    • /usr/sbin/ethtool -K enp2s0 gso off gro off tso off
    • Result: Packet loss disappeared, but the latency/jitter remains erratic and extremely high (e.g., 10 ms, 73 ms, 899 ms, 1684 ms, etc.).
  3. Flow Control: I attempted to disable Flow Control (rx-flow-ctrl off tx-flow-ctrl off), but the command failed with a netlink error: Operation not supported, suggesting the driver lacks support for this specific toggle.
  4. Hardware Test: Based on advice, I suspect a PHY chip incompatibility with my current switch and am looking into models based on Marvell/Broadcom PHYs, but I want to ensure no software fix remains.
The only stable workaround I have found is to force the network connection to $1000\text{ Mbps}$ (1 Gbps) using the following ethtool command:

Code: 
/usr/sbin/ethtool -s enp2s0 autoneg on advertise 0x025

When the speed is forced to $1\text{ Gbps}$, the network becomes perfectly stable.

System Information​


Here are the details from my system showing the current setup on the main Ethernet interface (enp2s0):

Code: 
=== INTERFACES ===
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
        valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
        valid_lft forever preferred_lft forever
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master vmbr0 state UP group default qlen 1000
    link/ether 78:55:36:03:fe:1d brd ff:ff:ff:ff:ff:ff
    altname enx78553603fe1d
... [Other VNETs/Bridge Config Omitted] ...
4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 78:55:36:03:fe:1d brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.2/24 scope global vmbr0
        valid_lft forever preferred_lft forever
    inet6 fe80::7a55:36ff:fe03:fe1d/64 scope link proto kernel_ll
        valid_lft forever preferred_lft forever

=== MATERIEL & PILOTE ===
02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller [10ec:8125] (rev 0c)
        Subsystem: Realtek Semiconductor Co., Ltd. Device [10ec:0123]
        Kernel driver in use: r8169
        Kernel modules: r8169

Request for Help​


Given that the issue persists even after driver and offloading adjustments:

  1. Has anyone experienced this specific extreme latency/jitter issue with the Beelink SER5 (RTL8125) on Proxmox 9.0.11?
  2. Are there any known kernel boot parameters or BIOS settings (on the Beelink) that might stabilize the 2.5G link?
  3. Are there any further ethtool flags I can try to fix the jitter (e.g., related to buffer size, even if Flow Control cannot be disabled)?
Thank you in advance for your assistance!
 
After updating to version 9.1.1 today, I'm experiencing problems with my RTL8125 network adapter.
I'm using the RTL8125 in passthrough mode to a virtual machine, but it keeps disconnecting and then reconnecting repeatedly.
Everything was working fine before the 9.1.1 update.
 
Hi,
I seem to be suffering from the same / a similar issue.
I noticed after yesterdays upgrade to 9.1.1 that pinging my node and the first LXC, I loose 40-50% of packets.
Sadly I can not state, if this was different before the update.

Current environment:
Code: 
# uname -a
Linux pve 6.14.11-4-pve #1 SMP PREEMPT_DYNAMIC PMX 6.14.11-4 (2025-10-10T08:04Z) x86_64 GNU/Linux

# pveversion
pve-manager/9.1.1/42db4a6cf33dac83 (running kernel: 6.14.11-4-pve)

# /usr/sbin/ethtool enp1s0
Settings for enp1s0:
        Supported ports: [ TP    MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
                                2500baseT/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half
                                100baseT/Half
                                1000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Full
        Link partner advertised pause frame use: Symmetric Receive-only
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Auto-negotiation: on
        master-slave cfg: preferred slave
        master-slave status: slave
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        MDI-X: Unknown
        Supports Wake-on: pumbg
        Wake-on: d
        Link detected: yes

The proposed workaround from original thread creator is not fixing the problem for me.

Update;
It might be a faulty cable after all?
Moved the PVE node back to its rightful place, port and cable and the issue is gone.
I will try to verify, if it is indeed the cable/port.That only the node and the first LXC were affected, does not fit to a cable/port issue.
It might be, that I now run 6.17.2-2.
 
Last edited:
You must log in or register to reply here.
Top Bottom
Back