I can fix that slow WiFi for you….

*** Updated *** – Corrected the command for enabled autotuning.

I travel a fair amount which means I live on WiFi connections to stay connected. When I first started using Vista I noticed that I had problems with some WiFi connections. The issues could anything from not being able to resolve DNS to no mail flow. The most obvious issue is very slow or complete failure to load a web page ( we have documented a few specific issues here).

The issue revolves around a new feature in the Windows Vista TCP stack called TCP Autotuning. Autotuning lets Vista monitor network conditions and adjust the TCP Receive Window. In the olden days you could make these changes manually with some reg hacks but this was inefficient since a change network conditions would require another manual reg hack. Vista can do this on the fly now which should mean that through-put on gigabit, high-latency and WAN links should improve.

The problem we run into is that some older networking hardware does not handle TCP Scaling very well (or at all). I have experienced this on WiFi at a a few trade shows in the past and at some hotels that implemented WiFi very early in the Internet gold rush. On some occasions it has impacted wired connections at hotels though that has been a very rare occurrence.

Fixing the issue is pretty straightforward. First, to see if you have Autotuning enabled, issue the following command at an elevated command prompt –

netsh interface tcp show global

You should get something back that looks like this…


I am currently set to have autotuning enabled (I am also at home right now where I have a gigabit network and all Vista clients and soon to be all Win 2008 servers). I leave this setting alone until I go out on the road and start having connectivity issues.

If I head out on the road and end up at a hotel where my connection seems very slow, I have a problems connection to my home servers via RDP, or I can’t establish a VPN back to MS, I will disable the TCP Autotuning with this command –

netsh interface tcp set global autotuning=disabled

When I get back home or go to a location where I know autotuning isn’t an issue, I turn it back on with the following command –

netsh interface tcp set global autotuning=normal

*** Updated *** – you can also set autotuning= to ….

disabled = disabled autotuning and sets to default value

restricted = Allow the receive windows to grow in a restricted fashion

highlyrestricted = Allow the receive window to grow but be very, very conservative with adjustments

experimental = normally only used in testing. Should not typically be used in production. Can can severe reduction in performance.

Keep in mind that if you have User Account Control enabled, you will have to issue those commands at an elevated CMD prompt.

I mentioned this issue at my launch event in Anchorage last week. I also mentioned that I have a couple of batch files to do this for me so I don’t have to do as much typing. You can grab the batch files here. There are two batch files with self-explanatory names to either enable or disable autotuning.

This blog goes into a little more detail on the issue and fixes. It also mentions another option of setting autotuning to "restricted". I have had limited success with this and stick to either on or off.



Comments (1)

  1. Christopher Krull says:


    Shouldn’t the command to reenable be this

    netsh interface tcp set global autotuning=enabled