One of the perennial problems I see no matter where I work or who I contract for is mysteriously slow network speeds to or from a Windows machine. I’ve amassed quite a list of tips and tricks for addressing this issue, and now I’m listing them all here.
I won’t go into a thorough treatment of exactly what’s going on with each command and feature that is being enabled or disabled. I’ll leave that as an exercise for the reader. This is a quick-n-dirty jumping off point for deeper problem resolution procedures. Also, these troubleshooting steps are not offered in any particular order, with the exception of the first four which try and scope the problem down to hardware versus software.
With no further rambling, here is my list of tricks when trying to solve a slow network connection on a Windows host:
Start With the Physical Layer
It’s almost always the easiest thing to check and is more often the cause of problems than most people would suspect. Thanks to Pauska in the comment below for reminding me of this. Switch cables out, switch NICs if possible (I like to keep a USB NIC around for this), try different switch ports, wall jacks — everything. It’s quick work and can reap a quick reward. Plus, with the physical layer out of the way, you can trust the observations that you make in the software layer.
Boot From a Live CD
Remove the OS from the equation and see if you can isolate the issue to hardware. Grab a Live CD that has an OS on it with support for your hardware. Once you boot from it, perform some tests on the bandwidth to see if the problem still exists. If so, then you may be safer in assuming that the problem exists somewhere other than the operating system (unless the same configuration that’s causing the problem exists in both operating systems).
Search for Network Related Errors
Perhaps there’s a lot of collisions on the network or the network card is having a large amount of CRC errors. A quick way to see current TCP/IP statistics is to run
netstat -s. Look for any interesting numbers that speak to receive errors or re-transmissions.
Use Performance Monitor counters to analyze error data live. If errors and re-transmissions seem unusually high, you have a jumping off point for further exploration.
Inspect Traffic with Network Monitor
Launch Microsoft Network Monitor or Wireshark (or whatever packet sniffer you prefer) and inspect the packet stream. There will almost certainly be a trail of information that can lead you to the ultimate problem. The trouble is: can you persevere to the end? It’s no easy thing to digest TCP conversations en mass.
In reality, this is where the root cause analysis will begin and often where it will end. However, if you want to flail at some network related options to try and narrow down the culprit, read on.
Disable Windows Network Task Offloading
Add a DWORD registry key titled ‘DisableTaskOffload’ with value of 1 to the registry hive HKLMSYSTEMCurrentControlSetServicesTcpipParameters.
Check that it currently exists and what the value is with the following PowerShell cmdlet:
get-itemproperty -path HKLM:SYSTEMCurrentControlSetServicesTcpipParameters -name "DisableTaskOffload"
Check the whole parent hive if you want:
get-itemproperty -path HKLM:SYSTEMCurrentControlSetServicesTcpipParameters
Create the new registry entry:
New-ItemProperty "HKLM:SYSTEMCurrentControlSetServicesTcpipParameters" -Name "DisableTaskOffload" -Value 1 -PropertyType "DWord"
Disable TCP chimney offloading
You will need to disable TCP offloading in the Windows OS as well as the hardware’s drivers, however we’ll talk more about disabling hardware offloading in the next point. By the way, TCP offloading only works if it is enabled both in Windows and in the hardware’s driver.
First, let’s check to see if any connections are currently offloaded to hardware using
InHost means that the TCP connection is being handled… well… in the host. If there are connections being offloaded to the hardware, know that disabling this will wreak some havoc with them.
To determine the state of offloading within the OS, run the following at a command prompt:
netsh int tcp show global
Look at the state of the “Chimney Offload State” setting. If it’s enabled, disable it with the following command:
netsh int tcp set global chimney=disabled
Disable All Hardware Network Offloading
Now you need to inspect your network card’s capabilities. Go to Device Manager, open up the properties of the NIC and select the Advanced tab. Search for any options that reference offloading. TCP, UDP, checksum, whatever. Disable it. “But! But! Offloading roxors!!” I know, this is just for troubleshooting purposes. Once you figure out where the bottleneck is, you can start determining the root cause. That’s for later though.
Each card has different features and terminology, so I can’t be more specific. For now, just disable anything to do with offloading.
Disable Receive Side Scaling
Check to see if it’s enabled with the following command:
netsh int tcp show global
Disable receive side scaling with:
netsh int tcp set global rss=disabled
Once again, check to see if it’s enabled with the following command:
netsh int tcp show global.
See if the registry key for the setting exists using PowerShell:
get-itemproperty -path HKLM:SYSTEMCurrentControlSetServicesTcpipParameters -name EnableTCPA
To disable it, create its registry key and give it the proper value. Using PowerShell:
New-Item -Path HKLM:SYSTEMCurrentControlSetServicesTcpipParametersEnableTCPA New-ItemProperty "HKLM:SYSTEMCurrentControlSetServicesTcpipParameters" -Name "EnableTCPA" -Value 0 -PropertyType "DWord"
Check to see if autotuning is enabled with:
netsh interface tcp show global
Disable it with:
netsh int tcp set global autotuning=disabled
Uninstall Remote Differential Compression
Go to Add/Remove Programs or Programs and Features (run >> appwiz.cpl). Choose the option to turn Windows features on or off. Uninstall Remote Differential Compression.
More information about RDC can be found at the Wikipedia page on Remote Differential Compression.
Alter NIC and Switch Port Speed and Duplex Settings
First, document your NICs current link speed and duplex settings. Then document the switch port’s settings.
In Windows, go into Device Manager, open the NIC in question and go to the advanced tab. The exact naming of the property for the card’s speed and duplex settings will vary, but you’ll know it when you see it.
Auto-negotation can be a pain. Set your NIC to 100 or 1000 Mbps Full Duplex if possible. Continue to frob with the possibilities. Personally, I wouldn’t bother with half-duplex settings, but – as they say – any port speed in a storm!
Update your NIC Drivers
Sounds simple. Sounds stupid. It works. Do it.
Not only should you use the latest drivers, but also look for discussions concerning your network card and its performance relative to the driver version. Perhaps it’s an older driver that you need. See if you can track down older versions and try those.
Check for Third Party Security Tools
If an antivirus utility is set to scan live traffic for malicious payloads, that can negatively impact throughput. Check to see what security tools are installed on the node that is having throughput problems and temporarily disable any features that affect live traffic.
Reset the TCP/IP Stack
You know that you’re flailing when you start resetting the TCP/IP stack. Read more about the procedure in Microsoft KB299357. At an elevated command prompt, run the following command:
netsh int ip reset resetlog.txt
To read more about the practice of repairing winsock2 corruption read Microsoft KB811259. To reset winsock, use the following command:
netsh winsock reset
Reset only the catalog with the following command
netsh winsock reset catalog
Note that if you are using Windows XP SP1 or earlier, you will have to manually reset winsock using the instructions in Microsoft KB811259.
Do you have any tips or tricks for a slow Windows network connection? Let me know in the comments below and I’ll include them here!