Troubleshooting a 10GbE Network: Why My Speed Dropped to 300 Mbps

In a recent effort to modernize my homelab, I began migrating my storage to a UniFi UNAS Pro 8. On paper, the hardware is formidable, but the real-world performance was initially abysmal.

🛠️ The Hardware Stack

My network topology consists of three primary nodes:

1. IRONHEART (Main Desktop): Equipped with an Intel E610-XT2 10GbE network card.
2. UniFi UNAS Pro 8 (NAS): 10GbE connectivity, featuring:
   • Six 16 TB HDDs configured in RAID 6.
   • Dual NVMe SSDs acting as a cache layer.
3. Minisforum MS-01 (MiniPC): 10GbE SFP+ connection, hosting Portainer and Immich.

📉 The Problem: "Sad-Making" Speeds

Despite the 10GbE infrastructure, SMB file transfers were crawling. I was seeing speeds between 100 and 200 megabits per second. Given that Immich was constantly reading metadata and thumbnails from the NAS, I suspected a bottleneck.

Initial theories included:

• SMB Signing issues
• Windows Defender network scanning
• Disk I/O saturation
• RAID 6 write penalties

🔍 The Isolation Process

To find the root cause, I had to test the NAS stop testing the storage entirely. I used iperf3 to test the raw network throughput between the Windows desktop and the MS-01.

The Asymmetry Discovery

The results were bafflingly inconsistent:

By removing the NAS, RAID, and SMB from the equation, I realized this was a Windows/NIC specific issue.

🛠️ The Fix: Part 1 (Receive Buffers)

I checked the adapter statistics using PowerShell: Get-NetAdapterStatistics -Name "Ethernet - 10 Gig Intel"

The output revealed nearly one million ReceivedDiscardedPackets. A quick 10-second test saw that number climb by another 268. I noticed the Receive Buffers were set to the default 512, despite supporting up to 4096.

Set-NetAdapterAdvancedProperty `
  -Name "Ethernet - 10 Gig Intel" `
  -DisplayName "Receive Buffers" `
  -DisplayValue "4096"

Result: Discarded packets dropped to zero, and receive throughput climbed to 5.15 Gbit/sec. However, the transmit speed remained stuck at a miserable 313 Mbit/sec.

🛠️ The Fix: Part 2 (LSO V2)

The final culprit was Large Send Offload (LSO) V2 for IPv4.

LSO is designed to reduce CPU overhead by allowing Windows to pass large TCP buffers to the NIC, which then segments them into smaller packets. While generally useful, Microsoft notes that this can actually decrease maximum throughput on certain hardware.

I disabled it via PowerShell:

Set-NetAdapterAdvancedProperty `
  -Name "Ethernet - 10 Gig Intel" `
  -DisplayName "Large Send Offload V2 (IPv4)" `
  -DisplayValue "Disabled"

🚀 The Final Results

After disabling LSO, the iperf3 test jumped from $\approx 313 \text{ Mbit/sec}$ to 7.03 Gbit/sec.

When I returned to the original real-world test (copying a large file to the UNAS), Robocopy reported a speed of 350,201,354 Bytes/sec. To put that in perspective:

$\text{350 MB/s} \times 8 \approx 2.8 \text{ Gbit/sec}$

This is a sustainable, real-world SMB write speed for a six-disk RAID 6 array.

⚠️ Important Disclaimer: I am not suggesting that everyone disable LSO. It is typically a beneficial feature. In this specific instance, it was a failure of the interaction between my specific Windows build, the Intel E610-XT2 driver, and the firmware.

💡 The Key Takeaway

The most valuable lesson here isn't about a specific setting, but about methodology:

When your storage is mysteriously slow, you must eventually stop testing the storage.

By using iperf3, I stripped away the filesystem, the RAID cache, and the SMB protocol, shrinking the problem space until only the raw network remained.

---

TL;DR: LSO V2 for IPv4 was throttling my 10GbE card to 2004-era speeds. Disabling it on this specific machine boosted iperf3 results from 313 Mbit/sec to 7.03 Gbit/sec.

---

💬 Community Notes

• Redzuan Redza: Noted that this reminds them of the "TCP Chimney" issues in Windows 2003 SP2, where disabling a "helpful" feature was the only way to restore stability.
• kitmanson: Suggested that an alternative OS might avoid these driver-level headaches.