Network File Transfer Slows Down After a Few Seconds — Quick Fix
Your transfer starts fast then drops to a crawl. The cause is usually a buffer or flow control setting — here's how to fix it.
You start copying a big file over your network — it blazes along at 100 MB/s, then after five seconds it plummets to 10 MB/s and stays there. Maddening, right? Here's the fix, then the explanation.
The Immediate Fix
On Windows 10/11, open Device Manager, find your network adapter (usually Realtek, Intel, or Killer), right-click it, go to Properties → Advanced tab. Look for these two settings and change them:
- Large Send Offload (IPv4) — set to Disabled
- Receive Side Scaling — set to Disabled
Apply, reboot. Test your file transfer again. If it's fixed, great. If not, also try disabling TCP Checksum Offload (IPv4) on the same tab.
On Linux (say, a NAS or server running Ubuntu/Debian), run this one-liner:
sudo ethtool -K eth0 tx off rx off sg off tso off gso off gro off lro offReplace eth0 with your actual interface name (check with ip a). Then restart the transfer.
If you're using macOS (Ventura or later), you can't easily tweak NIC offloads via GUI. But you can use the Terminal:
sudo sysctl -w net.inet.tcp.tso=0
sudo sysctl -w net.inet.tcp.rfc1323=0Reboot or restart the network interface.
Why This Works
What's actually happening here is that your network adapter's hardware offload features are trying to be smart — but they're causing bufferbloat at the NIC level. When you start a transfer, the adapter uses its onboard processor to split up TCP segments (TSO/LSO) or compute checksums. That's fine for the first few seconds because the system's buffer is fresh. But after a few seconds, the adapter's small internal buffer fills up, and it starts dropping packets or stalling. Your transfer goes from bursty to throttled.
The reason step 3 works: disabling those offloads forces the CPU to handle segmentation and checksums. On modern CPUs (Intel i5/i7, AMD Ryzen), the CPU does this faster and more reliably than the cheap NIC chips. The trade-off is a tiny increase in CPU usage — like 1-2% — which is invisible for file transfers. The gain is stable throughput.
Also, if you have Jumbo Frames enabled on the adapter (MTU 9000) but your switch doesn't support it properly, you'll see the exact same pattern: burst then drop. Disable jumbo frames on the adapter (set MTU back to 1500) if you're not 100% sure your whole path — PC, switch, router, NAS — supports it.
Less Common Variations
Sometimes the fix above doesn't work because the bottleneck isn't the NIC — it's the protocol or software stack.
SMB Multichannel gone wrong
On Windows, SMB Multichannel can cause speed drops if your network has multiple paths but one path is slower. The fix: disable SMB Multichannel temporarily. Open PowerShell as admin and run:
Set-SmbClientConfiguration -EnableMultiChannel $falseReboot. If transfers stabilize, your network topology is causing issues (mix of 1GbE and 2.5GbE ports, or bad cable). Re-enable it later after fixing the hardware.
NFS over TCP with low window size
On Linux NFS clients, the default TCP receive window can be too small for high-latency links. The transfer bursts, then waits for ACKs. Check with:
cat /proc/sys/net/ipv4/tcp_rmemIf the second value (default) is below 131072 (128 KB), bump it:
echo '4096 131072 6291456' > /proc/sys/net/ipv4/tcp_rmemMake it permanent by adding net.ipv4.tcp_rmem = 4096 131072 6291456 to /etc/sysctl.conf.
Wi-Fi interference pattern
On Wi-Fi 5/6, if you see speed drop after exactly 5-10 seconds, check for Bluetooth interference. Bluetooth on the same board (common in laptops) uses the same 2.4 GHz band. Turn off Bluetooth in your system tray and retest. The pattern is consistent because Bluetooth hops frequencies every few seconds.
Prevention
Don't just disable everything. Keep a baseline. After you find a stable config, note it down. For Windows, export the adapter settings via:
Get-NetAdapterAdvancedProperty -Name "Ethernet" | Export-Csv adapter_settings.csvOn Linux, save the ethtool settings in a startup script under /etc/network/interfaces or a systemd service. On macOS, the sysctl changes can go into /etc/sysctl.conf.
Also, test with iperf3 before blaming the network protocol. Iperf3 isolates raw TCP throughput. If iperf3 shows the same drop pattern, it's a NIC or cable issue. If iperf3 stays fast but file transfers drop, the problem is in the file-sharing layer (SMB, NFS, AFP) — then look at SMB Multichannel or NFS mount options like rwsize=65536.
Finally, update your NIC driver. I've seen Realtek 2.5GbE drivers from 2020 that had a known TSO bug. The 2023 driver fixed it. Check your manufacturer's site — not Windows Update — for the latest.
Was this solution helpful?