If you are looking for a solution, head to the end of this article.
With the coming of Vista Microsoft decided it was time for them to rewrite the networking layer in the Windows operating system. Like it or not, what networking started out as being in the days of Windows 3.11 has changed drastically. Unfortunately, the new implementation is not perfect and that is easily justifiable.
Rather than explore the boring details we will jump to those that are responsible for millions of gray hair strands all over the IT world. The first being Receive Window Auto-Tuning. In previous versions of Windows, the TCP Receive Window (RWIN) was a constant you set it once and live with it regardless of your connection speed fluctuations. Now you are asking, what the heck is RWIN? In one sentence, it is the amount of packet data that can be transmitted to the receiver without waiting for acknowledgment. If you aren’t familiar with TCP, every packet sent must be acknowledged by the receiver. As packets are acknowledged they are removed from the receive window and new packets are loaded and transmitted.
An example to explain RWIN and its impact on bandwidth: Imagine the receiver is far away and I need to send him a 1000KB file. Let’s say RWIN is 10KB, and I, being the sender, can transmit 10KB in 10ms. It takes the receiver 20ms to receive 10KB. I initiate the sending and it takes me 10ms to saturate the receive window. Now I am waiting for the receiver to acknowledge. Total time spent by the sender waiting is 30ms! And the process repeats until the entire file is transmitted. We can improve this it seems. Let us set RWIN to 30KB. Now it takes me 30ms to transmit 30KB. By the time I have sent the last packet, I am receiving acknowledgments for the first packets. I can continue transmitting constantly without delay until I am done!
The above example illustrates the importance of an appropriately configured RWIN. In an ideal world, the PC should keep track of multiple RWIN values. This is because every network is loaded differently, with varying capabilities and latencies. A proper networking implementation should keep track of all the paths it has been to and keep track of the ideal RWIN values for each. Of course this solution is not ideal (given infinite resources, the impossible becomes possible) and we have to resort to a single possible value for RWIN at any given time.
Windows XP’s implementation of RWIN was quite primitive. With Vista and 7, Microsoft have introduced an auto-tuning layer for optimizing RWIN based on delay and transmission quality and probably 100,000 other variables. The good? Terrific for large high-latency WANs and local area networks. The bad? There is a “setting period” for autotuning. Beyond this setting period it remains somewhat permanent, until something drastically changes or traffic increases to one particular destination. This leads to strange behaviour at times, with data transmitting very quickly and poorly. To explain this one needs to examine the network packets with autotuning enabled/disabled (this is explained later).
Open up a command shell (Start > Run > cmd or Windows Key+R > cmd) and let’s take a look at your TCP settings:
C:\>netsh int tcp show global
netsh is the network shell, it contains almost every network setting one can imagine. The parameter we are interested in is “Receive Window Auto-Tuning Level”. It is probably set to “normal”. You can experiment with four possible values:
- normal
- highlyrestricted
- experimental
- disabled
To set it to one of the above values:
C:\>netsh int tcp set global autotuning=disabled
Check the globals again to make sure it has set. If you see a message at the bottom with something about heuristics it means the value is being overridden. To disable heuristics:
C:\>netsh int tcp set global heuristics=disabled
Upon modifying any TCP settings, a restart is required.
So when does this setting really matter? For the average user, it is probably just fine as it is. But if you use your PC as a server this might impact you significantly. The best way to determine what is best for your computer is to test systematically. And to really see autotuning at work, get a copy of Wireshark (PortableApp version recommended) and monitor those packets. Ideally you want to test local transfers and WAN transfers with access to both sender and receiver.
Everything in this article also applies to Windows Server 2008 and 2008 R2.