Hi, my name is Katarzyna and I am the Program Manager within the Internet Protocols team. I have been asked a few times about the Receive Window Auto-Tuning feature on Vista and some associated issues people are having.
Mar 29, 2010 The default auto-tuning level is 'normal', and the possible settings for the above command are: disabled: uses a fixed value for the tcp receive window.
One of the many cool new features on Windows Vista, Receive Window Auto-Tuning enables the networking stack to receive data more efficiently than on XP. Auto-Tuning allows the operating system to continually monitor the routing conditions (bandwidth, network delay, application delay) and configure connections (scale the TCP Receiving Window) so as to maximize the network performance.In some high bandwidth, high latency links, we have seen SMB performance improvement up to 20 times!
Receive Window Auto-Tuning Level: normal restricted (heuristic) Add-On Congestion Control Provider: none ECN Capability: disabled RFC 1323 Timestamps: disabled. The above autotuninglevel setting is the result of Windows Scaling heuristics overriding any local/policy configuration on at least one profile. TCP Receive Window Auto-Tuning Level feature in Windows Content provided by Microsoft Applies to: Windows 10 Windows 8.1 Windows 8 Windows 7 Windows Vista Windows Server Windows Server 2016 Windows Server 2012 R2 Windows Server 2012 Windows Server 2008 R2 Windows Server 2008 More.
Jan 08, 2018 Window Auto-Tuning feature is said to improve the performance for programs that receive TCP data over a network. It is nothing new. It was introduced in Windows Vista and is present in Windows 10 too. In today’s Internet, the range of latencies & throughput speeds is. By default, Windows in normal auto tuning level will use RWIN size of 256 bytes with a scale factor of 8. This value is not suitable for all routers and servers which does not support TCP scale factor, and continue to communicate with 65536 bytes (64kB). 64kB is the fixed default TCP receive buffer, and through autotuning it can scale up to 16 MB.
In every TCP packet there is a 'window' field, which informs the receiver how much data the sender can accept back. This window controls the flow by setting a threshold on data kept 'in flight' and prevents overwhelming the receiver with data that it cannot accept.
The TCP window field is 16 bits wide, allowing for a maximum window size of 64KB, which used to meet requirements of many older networks. Nowadays, however, network interfaces can handle larger packets and keep more of them in flight at any given time. Thus, a larger TCP window has become necessary; especially on high-speed, high latency networks. To fill such a long, fat pipe and make use of the available bandwidth, the sending system can often require very large windows for good performance.
The solution to this demand is called 'window scaling”, described back in 1992 in RFC 1323. It introduces an eight-bit scale factor, which serves as a multiplication factor for the window width. After the factor has been negotiated, window values used by that system on a given connection will be shifted to the left by that scale factor; a window scale of zero, thus, implies no scaling at all, while a scale factor of six implies that window sizes should be shifted six bits, thus multiplied by 2^6 = 64. Now a window greater than 64KB can be easily expressed (e.g., 128KB) by setting the scale factor (e.g., 6) and keeping the window field under the original 16 bits (here, 2048).
The window size included in all packets is modified by the scale factor, which is negotiated once at the very beginning of a TCP connection. The connection requestor suggests window scaling factor in its original SYN packet and if the SYN+ACK packet sent in response contains the option, then this particular value will be used on this connection. The scale factor cannot be changed after the initial setup handshake; remaining data transfers on this connection will implicitly use the negotiated value.
Older routers and firewalls however do not handle window scaling correctly leaving the option in the original SYN packet but setting the connection’s scale factor to zero. Seeing the option on, the receiver responds with its own window scale factor. Believing that its scale factor has been accepted, the initiator scales the window appropriately while the receiver thinks that a scale factor of zero is applied and thus a small window of data should follow. As a result, the communication is slow at best. Sometimes, small window packets are dropped by the routers, essentially breaking the connection.
The resulting slow data transfers or loss of connectivity, users may experience as slow or hung networking applications. Remote Desktop Connection and network file copy are two scenarios particularly hurt by misbehaving routers.
If your connection from a Vista machine appears slow or hung, here are some steps to isolate the cause:
Please refer to the following KB articles for more information:
-- Katarzyna
Updated: Broken link to KB 932170
Update 2: Changed the guidance to do restricted before disabled.
Update 3: tunning doesn't have two 'n's. :)
Update 4: no really, tuning doesn't have two 'n's.
Note: We use Linux for our high-performance hosts, and don't have any MS Windows expertise in house. Please help us keep this page up to date by sending us updates. Thanks!
Versions of Microsoft Windows, starting with Vista and progressing through 10, include the ability to use a variety of TCP Autotuning and have some controls over buffer management.
The 'PowerShell' is the mechanism that can be used to modify some of the settings of the TCP stack. More information can be found here:
This command changes the custom TCP setting to have a value of 64 for the initial congestion window and use 'Compound TCP' (an advanced TCP congestion control algorithm which is similar to cubic on Linux). The 'InitialCongestionWindowMss' specifies the initial size of the congestion window, and it can be an even number from 2 through 64.
Other useful settings include:
Specifies a TCP auto-tuning level for the host computer. TCP auto-tuning can improve throughput on high throughput, high latency networks
T-pain sing without auto tune. Specifies whether to enable timestamps. Timestamps facilitate round trip measurement, and can help protect against wrapped sequence numbers on high throughput links. For more information about TCP timestamps, see RFC 1323. The acceptable values for this parameter are:
Specifies whether to enable ECN capability. The acceptable values for this parameter are:
Vista and 7 will use up to a 16 MB maximum receive window, 8 and 10 can theoretically support up to 1G.
These varieties support an advanced TCP congestion control algorithm called 'Compound TCP (CTCP)', which is similar to cubic on Linux. To enable this in Vista and 7, set the following:
If you even need to disable / re-enable autotuning, here are the commands:
Note: You have to have administrator rights for these commands to work.
To launch a command prompt with administrator rights:
Click start
Type CMD.EXE in the search box
Press SHIFT+ CTRL+ENTER
select yes in the UAC dialog box.
There is no way to adjust the default TCP buffer in Vista/7, which is 64 KB. Also, the Windows Vista/7 autotuning algorithm is not used unless the RTT is greater than 1 ms, so single stream TCP will be throttled on a LAN by this small default TCP buffer.
Note: We have received reports that on Windows 2008 R2 server, TCP window scale is broken when the RTT is between 1 and 8ms. Hopefully there will be a patch soon.
Recommended: | Windows 7, Vista, 2008 Tweaks |
TCP Receive Window Auto-Tuning in Vista | |
Enterprise Networking with Windows Vista |
Note that the tuning settings described here may decrease performance of hosts connected at rates of OC3 (155 Mbps) or less, such as home users on Cable/DSL connections.
The easiest way to tune TCP under Windows XP is to get DrTCP from 'DSL Reports'. Set the 'Tcp Receive Window' to your computed BDP (e.g. 4000000), turn on 'Window Scaling' 'Selective Acks', and 'Time Stamping'.
Other programs that allow you to edit Windows TCP settings include SG TCP Optimizer.
To verify the changes, you can use the Windows Registry editor to verify the following:
Recommended: | Windows network tuning. |
Useful: | |
Windows 2000/XP Registry Tweaks |