Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
To check the current status of the Vista TCP/IP tweakable parameters, in elevated command
prompt type the following command:
netsh int tcp show global
You will be presented with something like the following:
The settings, as well as their default and recommended state are explained below. The two most
important tweakable parameters are "Auto-Tuning Level" and "Congestion Control Provider".
When checking the TCP state with the "netsh int tcp show global" command, it is also possible
to see the following message below all those parameters:
** The above autotuninglevel setting is the result of Windows Scaling heuristics overriding any
local/policy configuration on at least one profile.
It is displayed when the "Receive Window Auto-Tuning Level" is not explicitly set, or if the
system deemed it necessary to make a change because of user prompted "repairing" of your
network connection, for example.
TCP Auto-Tuning
To turn off the default RWIN auto tuning behavior, (in elevated command prompt) type:
netsh int tcp set global autotuninglevel=disabled
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. Limits it to 64KB (limited at 65535).
highlyrestricted: allows the receive window to grow beyond its default value, very
conservatively
restricted: somewhat restricted growth of the tcp receive window beyond its default value
normal: default value, allows the receive window to grow to accommodate most conditions
experimental: allows the receive window to grow to accommodate extreme scenarios (not
recommended, it can degrade performance in common scenarios, only intended for research
purposes. It enables RWIN values of over 16 MB)
Our recommendation: normal (unless you're experiencing problems).
If you're experiencing problems with your NAT router or SPI firewall, try the "restricted",
"highlyrestricted", or even "disabled" state.
Notes:
- Reportedly, some older residential NAT routers with a SPI firewall may have problems with
enabled tcp auto-tuning in it's "normal" state, resulting in slow speeds, packet loss, reduced
network performance in general.
- auto-tuning also causes problems with really old routers that do not support TCP
Windows scaling. See MSKB 935400
- netsh set commands take effect immediately after executing, there is no need to reboot.
- sometimes when using "normal" mode and long lasting connections (p2p software / torrents),
tcp windows can get very large and consume too much resources, if you're experiencing
problems try a more conservative (restricted) setting.
If you're experiencing problems with Auto-Tuning, see also:
MS KB 835400 - email issues
MS KB 934430 - network connectivity behind firewall problems
MS KB 940646 - 3G WWAN throughput issues
MS KB 929868 - web browsing issues
MS KB 932170 - slow network file transfer
ECN Capability
ECN (Explicit Congestion Notification, RFC 3168) is a mechanism that provides routers with an
alternate method of communicating network congestion. It is aimed to decrease retransmissions.
In essence, ECN assumes that the cause of any packet loss is router congestion. It allows routers
experiencing congestion to mark packets and allow clients to automatically lower their transfer
rate to prevent further packet loss. Traditionally, TCP/IP networks signal congestion by dropping
packets. When ECN is successfully negotiated, an ECN-aware router may set a bit in the IP
header (in the DiffServ field) instead of dropping a packet in order to signal congestion. The
receiver echoes the congestion indication to the sender, which must react as though a packet drop
were detected.
ECN is disabled by default in Vista and other modern TCP/IP implementations, as it is possible
that it may cause problems with some outdated routers that drop packets with the ECN bit set,
rather than ignoring the bit. To check whether your router supports ECN, you can use the
Microsoft Internet Connectivity Evaluation Tool. The results will be displayed under "Traffic
Congestion Test".
To enable ECN, in elevated command prompt type:
netsh int tcp set global ecncapability=enabled
Possible settings are: enabled, disabled, default (restores the state to the system default).
The default state is: disabled
Recommendation: enabled (only for short-lived, interactive connections and HTTP requests with
routers that support it, in the presense of congestion/packet loss), disabled otherwise (for pure
bulk throughput with large TCP Window, no regular congestion/packet loss, or outdated routers
without ECN support).
Notes: ECN is only effective in combination with AQM (Active Queue Management) router
policy. It has more noticeable effect on performance with interactive connections and HTTP
requests, in the presense of router congestion/packet loss. Its effect on bulk throughput with large
TCP Window are less clear.
More information on ECN: Explicit Congestion Notification (ECN) for TCP/IP
Default state: disabled (under Vista), automatic (under Windows 7 and 2008 Server)
Recommended: enabled
The possible states are disabled, enabled, default (Vista), automatic (only Windows 7 and 2008
Server) as follows:
automatic - This default setting is only available under Windows 7 and 2008 Server, it is not
available udner Vista. It offloads if the connection is 10 GbE, has a RTT < 20ms, and the
connection has exchanged at least 130KB of data. The device driver must also have TCP
Chimney enabled.
default - this setting restores chimney offload to the system default. Setting this "default"
state under Windows 7 and 2008 Server is possible, but it sets the system to the "automatic"
mode described above.
disabled - this setting is maually configured as disabled.
enabled - this setting is manually configured as enabled.
Notes:
Under Windows 7 and Server 2008 the "default" and the additional "automatic" parameter set
the system to the same "automatic" state.
For Chimney Offload to work, it needs to be enabled in both the OS and NIC. To enable the
"TCP Offloading" setting in your NIC, navigate to the Device Manager, under Network
Adapters, in the Advanced tab, and check "Enabled" in the box next to the TCP offload entry.
Setting MTU
It is sometimes useful to view and set the MTU value for a specific network interface manually.
To view a list of active network interfaces and their MTU values in Vista using netsh, open
command prompt as administrator and execute the following command:
netsh interface ipv4 show subinterface
You will be presented with a list of interfaces, and their respective MTU values as follows:
To change the MTU value of a specific network card, type the following in command prompt:
netsh interface ipv4 set subinterface "network interface name" mtu=#### store=persistent
Where "network interface name" is your specific network adapter name as obtained above (or
viewable under Network adapters), and mtu=#### is the desired MTU value.
For example, if the name of your network card is "Wireless Network Connection" and you'd like
to set its MTU to 1500, you'd have to type:
netsh interface ipv4 set subinterface "Wireless Network Connection" mtu=1500
store=persistent
Note: The maximum MTU value is usually 1500, and up to 1492 for PPPoE connections.
Manually tuning Registry Parameters
Many of the registry keys tuning TCP/IP parameters from previous Windows versions no longer
work in Vista and Server 2008. Below is a list of the few we've confirmed to still work. Note that
for changes to these settings to take effect the computer needs to be rebooted. As always, a
registry backup is recommended if making any changes, and some proficiency in using regedit is
required.
In regedit (Start icon > Run > type: regedit while logged in as administrator), you can navigate
and edit the following keys.
MTU (Maximum Transmission Unit) - the maximum packet size.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces
\{...}\
MTU=1500 (DWORD, entry does not exist by default)
The {....} part of the above path is the unique identifier of your network adapter. You can
recognize the correct adapter by looking at it's IP address, if obtaining IP automatically labeled
by: DhcpIPAddress=192.168.x.x text value, for example.
We recommend leaving this at default, unless you want to lower it. Vista uses the largest
possible packet size for the underlying network by default.
Note: In some test environments, the correct MTU entry may be offset by 8. The 8 offset seems to
coincide with the size of the PPPoE overhead. Check the result with the TCP Analyzer.
NetDMA (TCPA)
NetDMA enables support for advanced direct memory access. In essence, it provides the ability
to more efficiently move network data by minimizing CPU usage. NetDMA frees the CPU from
handling memory data transfers between network card data buffers and application buffers by
using a DMA engine.
Under Windows 7, NetDMA can be set directly using the netsh interface (not available under
Vista):
netsh int tcp set global netdma=enabled
Under Vista/2008/7, you can set NetDMA/TCPA using the following Registry parameter:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
EnableTCPA=1 (DWORD, not in registry by default. Set to 1 to enable, 0 to disable NetDMA)
Recommended setting is 1, a new DWORD value may need to be created if not already present
in the registry.
Checksum Offloading (DisableTaskOffload)
This NDIS 5 setting allows for reducing CPU load by offloading some tasks required to maintain
the TCP/IP stack to the network card. Theoretically, Widnows should automatically detect
capable network hardware.
The tasks offloaded are as follows:
- TCP/IP checksum calculation - each packet sent includes a verification checksum.
- TCP/IP segmentation - also known as "TCP Large Send" where Windows sends a large amount
of data to the network card, and the NIC is then responsible for dividing it according to the
network MTU. Experimental feature, not enabled by default
- IPSec Encryption cyphers and message digests - provides encryption of packets at the hardware
level.
To change the checksum offloading setting in the Windows Registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
DisableTaskOffload=0 (DWORD value, default: not set, recommended: 0=enable offload,
1=disable offload)
Also see: MS KB 888750, MS KB 904946, MS KB 936702
DefaultTTL
TTL can be safely left alone in many cases. It is a limit to the time and number of hops/routers a
packet will travel before being discarded. A number that's too small risks packets being
discarded before reaching their destination. A number that's too large (over 128) will cause delay
in when lost IP packets are discarded.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
DefaultTTL=64 (DWORD, set to a decimal value between 32 and 128. Recommended: 64)
TcpMaxDataRetransmissions
Determines how many times unacknowledged data (non-connect segment) is retransmitted
before TCP aborts the connection. The retransmission timeout is doubled with each successive
retransmission on a connection. It is reset when responses resume.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
TCPMaxDataRetransmissions=7 (DWORD, recommended: between 3 and 10, not present in
registry by default)
Note: When not present in the registry, the default behavior is 255 retransmissions (5 in
documentation).
SynAttackProtect
This undocumented setting provides protection against SYN denial of service (DoS) attacks.
When enabled, connections timeout sooner if SYN attack is detected. When set at 1,
TCPMaxDataRetransmissions can be lowered further.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
SynAttackProtect=1 (DWORD, recommended: 1, not present in registry by default)
See Also
Windows Vista tcpip.sys connection limit patch for Event ID 4226 - removing the limit on half-
open TCP connections.
References
Windows Server 2008 Network Shell (Netsh) Technical Reference
Microsoft KB951037
RFC 2581
Wikipedia: Nagle's algorithm
Technet: TCPNoDelay
MS KB 311833
MS KB 328890
MS KB 321098
MS KB 321169
MS KB 951037 - TCP Chimney Offload, Receive Side Scaling, and Network DMA in Windows
Server 2008
User Reviews/Comments:
rate:
Top of Form
2574 article -- rating --
Bottom of Form
avg:
by Ev - 2008.07.28 04:01
I just followed your recommended Vista TCP/IP settings to increase my broadband internet
speed and my internet speed has improved significantly already without even closing my
browser, doing a clean-up, or restarting the PC. I did not try the registry edits. I think I will leave
those for now, unless I experience more problems with my internet speed. So far, it is much
better than before tweaking the settings.
Thanks!!!
:-)
HKEY_USERS.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings
"MaxConnectionsPerServer"=dword:00000010
"MaxConnectionsPer1_0Server"=dword:00000010 "
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces
\{...}\
MTU=1500 (DWORD, entry does not exist by default)
cheers!
So if gaming is your priority, it's a good tweak, but if you do a lot of file transfers, I suggest you
leave it on.
Any decent programmer who wrote the network code for these online games would disable
Nagle's Algorithm through the API--meaning that you wouldn't have to yourself. If you have to
disable Nagle's Algorithm globally to get a better ping in a game, then it's a failure of the
programmer who wrote the network code for the given game (e.g. WoW).
Now, the next thing I wanted to say, regardless of the pictures you have seen, or what some of
the so called 'experts' on the 'net say, disabling nagles is a bad thing. When you do you basically
break TCP/IP. In XP and Vista, the game doesn't work better because there is a flaw in the
windows TCP/IP, it seems to work better because the code in the game is crappy to begin with
and doesn't work properly with TCP/IP because the net code in the game that shapes the packets
it sends doesn't correctly form the packets and as a result produces a smaller packet and lots of
them, disabling nagles only seems to help because it makes TCP/IP more accpeting of the broken
non-standard packet from the game. Next, disabling nagles, while you may get a lower ping
reading in certain games, your really degrading your connection and bandwidth. The last thing I
wanted to say about adding this to Vista, it doesn't work in Vista contrary to popular belief even
if you turn off autotuning. Think about it, what happens when you turn off autotuning? So you
turn it off, lock the TCP window size, and then further degrade that by turning off nagles? Come
on now, get realistic folks.
---- So if we want to play WoW with better ping is this a better fix then trying to disable nagles
or should we do both. I understand WoW was programmed incorrectly so what is the consensus
on the best approach to fixing whatever you can
---------------------
Is he right or not?
For those slower than realtime games, based on TCP traffic (WC3), some tweaks may work at
the expence of throughput. It's simple as that. You modify the handling of packets to minimize
overhead and by doing so, the following apply:
- While gaming, you gain response time by sending smaller packets at a time and by not
resending useless data when network problems generates packet loss.
- While downloading, you loose speed by having more overhead, and when network problems
generates packet loss your speed gets slashed again for not having an optimized algorithm to deal
with it, because now there is no useless data.
What's too bad is that ISPs hurt you in this situation too, they dont tolerate things like MTU
tweak and so on.
Maniacs may try tweaking the advanced properties of their network card, like Jumbo Frame,
Large Send Offload and Flow Control and set them to off, at the expense of throughput.
Tweaking it yourself can result in crawling internet performance. Improper use can make a huge
downgrade, don't scratch your head when you get less than 10MB/s on your Gigabit enabled
LAN, when you should have got 60-80MB+.