Windows · Windows Server  ·  medium  ·  Networking & connectivity

Gigabit LAN transfers run at a fraction of the speed

The link negotiated is not the link being used. Copies crawl, small files worse than large ones.

What you see

A file copy over a gigabit network runs at 10–12MB/s or lower, or starts fast and collapses. Both machines are otherwise fine.

What is actually wrong

A duplex or speed mismatch on the switch port, an offload feature the driver implements badly, receive-side scaling disabled on a busy server, or SMB signing and encryption costing more than the network does.

Codes and articles

Large Send OffloadRSSduplex mismatchSMB signing

Fixes (3)

Check what the link actually negotiated
Elevated PowerShell10 minuteslow riskreversible

Slow in both directions. Establish the physical layer before anything else.

  1. Read the negotiated speed. Anything below 1Gbps on gigabit equipment is the answer.

    PowerShell
    Get-NetAdapter | Format-Table Name,Status,LinkSpeed,FullDuplex,MtuSize

  2. Look for errors — a bad cable shows here long before it shows anywhere else.

    PowerShell
    Get-NetAdapterStatistics | Format-Table Name,ReceivedDiscardedPackets,ReceivedPacketErrors,OutboundDiscardedPackets,OutboundPacketErrors

    Rising receive errors on a link that claims 1Gbps means the cable or the port, not the software. It is worth a two-minute cable swap before an afternoon of driver settings.

  3. Leave speed and duplex on Auto at both ends. A hard-set port against an auto port is the classic mismatch and produces exactly this.

  4. Swap the cable and the switch port and re-test before changing any driver setting.

Confirm it workedLinkSpeed reads 1 Gbps, error counters stay flat under load.
If you need to undo itNothing was changed.
Disable the offload features one at a time
Elevated PowerShell20 minutesmedium riskreversible

Transfers start fast and collapse — the signature of a broken offload implementation.

  1. Record the current state so it can be put back exactly.

    PowerShell
    Get-NetAdapterAdvancedProperty -Name 'Ethernet' | Format-Table DisplayName,DisplayValue | Out-File $env:USERPROFILE\Desktop\nic-before.txt

  2. Turn off large send offload, which is the usual culprit.

    PowerShell
    Disable-NetAdapterLso -Name 'Ethernet'

  3. Re-test. If it is still slow, try checksum offload and then receive-side coalescing, restoring each one before trying the next.

    PowerShell
    Disable-NetAdapterChecksumOffload -Name 'Ethernet'Disable-NetAdapterRsc -Name 'Ethernet'

    Changing them all at once fixes the symptom and teaches you nothing. One at a time takes twenty minutes and tells you which setting to document for the rest of the estate.

  4. Update the network driver from the manufacturer, then re-enable everything and test again — a fixed driver is better than a permanently disabled feature.

Confirm it workedA large file copy holds a steady rate for its whole duration.
PowerShell
Get-NetAdapterLso -Name 'Ethernet' | Format-Table Name,V1IPv4Enabled,IPv4Enabled
If you need to undo itEnable-NetAdapterLso, Enable-NetAdapterChecksumOffload and Enable-NetAdapterRsc restore the defaults; nic-before.txt has the original values.
Measure what SMB is costing before changing it
Elevated PowerShell on both ends25 minutesmedium riskreversible

Only file shares are slow, and only to certain servers.

  1. See the dialect, whether multichannel is in use, and whether it is signing or encrypting.

    PowerShell
    Get-SmbConnection | Format-Table ServerName,ShareName,Dialect,Encrypted,SignedGet-SmbClientConfiguration | Format-List EnableMultiChannel,RequireSecuritySignature,EnableBandwidthThrottling

  2. On the server, check the same.

    PowerShell
    Get-SmbServerConfiguration | Format-List EnableSMB2Protocol,RequireSecuritySignature,EncryptData,EnableMultiChannel

  3. If signing is required and the CPU is the bottleneck, the answer is a faster server or more channels — not turning signing off. Signing is what stops a man in the middle rewriting the files in transit.

    Every forum answer to this suggests disabling SMB signing. On a domain network it is required for SYSVOL by default and disabling it opens a real attack. Measure first.

  4. Enable multichannel if both ends have more than one adapter — it multiplies throughput without weakening anything.

    PowerShell
    Set-SmbClientConfiguration -EnableMultiChannel $true -ForceSet-SmbServerConfiguration -EnableMultiChannel $true -Force
Confirm it workedTransfer rate improves and the connection is still shown as Signed.
PowerShell
Get-SmbMultichannelConnection | Format-Table Server,ClientIpAddress,ServerIpAddress,CurrentChannels
If you need to undo itSet-SmbClientConfiguration and Set-SmbServerConfiguration accept the original values recorded in step one.

Related faults

"The specified network name is no longer available"Windows ServerDisk at 100% in Task Manager and the machine is unusableWindows0x80070035 — "the network path was not found" reaching a shareWindowsIntermittent connection failures where IPv6 is half-configuredWindowsBonded or teamed interfaces will not come up, or run at one link's speedLinux

Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.