Hi everyone,
I’m troubleshooting poor 5GbE performance across three Dell Proxmox hosts. Has anyone seen similar behavior or found a reliable fix?
Setup
With Micro and Slim connected directly, TSO enabled gave only ~12–13Mbps. Disabling TSO improved this to ~4.71Gbps in both directions with zero or very few retransmissions.
On the successful direct connection, both NICs reported RX/TX pause negotiated on. Through the switch/modules, pause negotiation reported off.
TSO is now disabled on all three nodes, but the switched problem remains.
What I’ve tried
Receiver misses are increases in rx_missed during each test. The last two tests used four TCP streams for ten seconds, with TSO off and GRO on.
At the same 400Mbps target, smaller application writes substantially reduced loss, but this hasn’t established a practical 5GbE fix.
I found this similar Proxmox report, describing 4.7Gbps one way and 400–500Mbps the other.
Has anyone resolved this pattern? I’d particularly appreciate working driver/kernel and switch combinations, or a targeted way to distinguish a Realtek receive-path issue from a switch/transceiver interaction.
I used AI to help organize my troubleshooting notes and summarize the results. I ran the tests myself; the measurements are from my command outputs, and I can provide the raw logs. No root cause has been confirmed.
I’m troubleshooting poor 5GbE performance across three Dell Proxmox hosts. Has anyone seen similar behavior or found a reliable fix?
Setup
- Realtek RTL8126A 5GbE NICs, using r8169
- Kernel: 7.0.14-24-pve
- Firmware: rtl8126a-3_0.0.5 08/30/24
- UniFi US-16-XG switch with UACC-CM-RJ45-MG copper SFP+ modules
- NICs negotiate 5000Mbps/full duplex; MTU 1500
- Separate Intel 1GbE NICs handle management. The Realteks are on an isolated test subnet.
- Micro, Slim and Plus below are the three hosts.
- Through the switch, some directions reach 4.6–4.7Gbps, while others manage only 500–600Mbps.
- Slow transfers produce thousands of TCP retransmissions, with accompanying increases in the receiving NIC’s rx_missed counter. Even the fast directions have substantial retransmissions.
- Realtek-to-Realtek ping is usually 3.5–5ms, compared with under 1ms over Intel.
- Connecting the Realteks to the switch’s native copper ports at 1Gbps previously gave ~943Mbps with zero retransmissions, although the high latency remained.
With Micro and Slim connected directly, TSO enabled gave only ~12–13Mbps. Disabling TSO improved this to ~4.71Gbps in both directions with zero or very few retransmissions.
On the successful direct connection, both NICs reported RX/TX pause negotiated on. Through the switch/modules, pause negotiation reported off.
TSO is now disabled on all three nodes, but the switched problem remains.
What I’ve tried
- Different cables and bypassing patch-panel couplers
- Ubiquiti and FS copper SFP+ modules
- Enabling switch flow control and reconnecting links; NIC pause negotiation still reported off
- Disabling GRO; no improvement, so it was restored
- EEE changes; no confirmed improvement
- A brief r8126 10.018.00 trial on one host; no confirmed fix, and it has since been removed
| Condition | Direction | Throughput | TCP retransmissions | Receiver misses |
|---|---|---|---|---|
| Direct cable, TSO on | Micro–Slim; direction not recorded | 12–13 Mbps | 5,286 | Not recorded |
| Direct cable, TSO off | Micro ↔ Slim | ~4.71 Gbps both ways | Zero/very few | Not recorded |
| Switched 5GbE, TSO off | Micro → Slim | 4.62 Gbps | 1,112 | Not recorded |
| Switched 5GbE, TSO off | Slim → Micro | 523 Mbps | 3,411 | 3,327 |
| Switched, 400Mbps target, default 128KB writes | Slim → Micro | 400 Mbps | 6,379 | 6,383 |
| Switched, 400Mbps target, 16KB writes | Slim → Micro | 400 Mbps | 79 | 79 |
At the same 400Mbps target, smaller application writes substantially reduced loss, but this hasn’t established a practical 5GbE fix.
I found this similar Proxmox report, describing 4.7Gbps one way and 400–500Mbps the other.
Has anyone resolved this pattern? I’d particularly appreciate working driver/kernel and switch combinations, or a targeted way to distinguish a Realtek receive-path issue from a switch/transceiver interaction.
I used AI to help organize my troubleshooting notes and summarize the results. I ran the tests myself; the measurements are from my command outputs, and I can provide the raw logs. No root cause has been confirmed.