Windows 2k/XP - More Tweaks2001.03.31 11:10 by Philip
Keywords: Registry, TCP/IP, Nagle, QoS, tweak, DNS
You can find our main Windows 2000/XP tweaks and patches here: Windows 2k/XP Registry Tweaks
Tweak DNS Errors Caching in Windows
All current Windows versions starting with Windows 2000 have built-in DNS (Domain Name System) caching, which basically caches resolved hostnames for faster access and reduced DNS lookups. This is generally a great feature, with the only downside that failed DNS lookups get cached by default as well... When a DNS lookup fails (due to temporary DNS problems), Windows still caches the unsuccessful DNS query, and in turn fails to connect to a host regardless of the fact that the DNS server might be able to handle your lookup seconds later.
There are a couple of different ways to tweak Windows not to cache failed DNS lookups:
1. You can flush the DNS cache manually, by going to Command Prompt and typing: ipconfig /flushdns
Or you can permanently solve this issue by tweaking a few Registry entries. You can simply use the patch below to modify your Registry:
winxp_dnscache.zip - patches for Windows 2000 and Windows XP not to cache failed DNS entries. To install, save to your HD and double-click the filename for your OS. Use the XP patch for Windows 2003 server.
If you'd rather do the changes manually, and assuming you feel comfortable editing the Windows Registry, here are the related Registry entries (recommended values are highlighted in red):
MaxNegativeCacheTtl=0 (DWORD, default value: 0x12C (300 seconds), range: 0x0–0xFFFFFFFF seconds) Description: Determines how long an entry recording a negative answer to a query remains in the DNS cache. When the time specified in the value of this entry expires, the DNS client deletes the answer record from cache. This is a Windows XP and 2003 Server setting only, the Windows 2000 equivalent is NegativeCacheTime.
NegativeCacheTime=0 (DWORD, default value: 0x12C (300 seconds), range: 0x0–0xFFFFFFFF seconds) Description: Determines how long an entry recording a negative answer to a query remains in the DNS cache. When the time specified in the value of this entry expires, the DNS client deletes the answer record from cache. This is a Windows 2000/2008/Vista/Windows 7 setting, for Windows XP/2003 please use MaxNegativeCacheTtl instead.
NetFailureCacheTime=0 (DWORD, default value: 0x1E (30 seconds), range: 0x0–0xFFFFFFFF seconds) Description: Determines for how long the DNS client stops sending queries when it suspects that the network is down. When the DNS client does not receive responses to repeated queries sent to any network adapter, the DNS client stops sending queries for the time specified in the value of this entry. During that time, the DNS client returns a timeout response to all queries. If the value of this entry is 0x0, this optimizing feature is disabled. DNS continues to send queries to an unresponsive network.
NegativeSOACacheTime=0 (DWORD. default value: 0x78 (120 secnds), range: 0x0–0xFFFFFFFF seconds) Description: Determines how long an entry recording a negative answer to a query for an SOA (Start of Authority) record remains in the Domain Name System (DNS) cache. When the time specified in the value expires, the DNS client deletes the answer record from the cache.
Note: As always when editing the Registry, a backup is a good idea, and reboot might be required for changes to take effect.
The following tweak applies only to Windows XP Professional edition (and other Windows versions that may have QoS Policy installed).
The default system behavior is that all 100% bandwidth is available, however, if there is a running application that indicates to the OS it needs to send high priority/real time data, then as long as it has the socket open, Windows XP will restrict "best effort" traffic to 80% of the bandwidth so that high priority traffic can be accommodated. Basically, applications can make this request to the operating system for QoS support using the QoS application programming interfaces (APIs) in Windows and this only applies if a specific app is requesting QoS.
1. Make sure you're logged in as "Administrator" (not just any account with admin privileges).
Under START > My Computer > My Network Connections > View Network Connections, right-click on your connection and under Properties (where it lists your protocols), make sure QOS Packet Scheduler is enabled.
Alternate Method (Windows Registry)
Instead of editing the group policy, one can edit the Windows Registry directly:
Gaming Tweak - Disable Nagle's algorithm
The tweak below allows for tweaking or disabling Nagle's alogrithm. Disabling "nagling" allows for very small packets to be transferred immediately without delay. Note that is only recommended for some games, and it may have negative impact on file transfers/throughput. The default state (Nagling enabled) improves performance by allowing several small packets to be combined together into a single, larger packet for more efficient transmission. While this improves overall performance and reduces TCP/IP overhead, it may briefly delay transmission of smaller packets. Keep in mind that disabling Nagle's algorithm may have some negative effect on file transfers, and can only help reduce delay in some games. To implement this tweak, in the registry editor (Start>Run>regedit) find:
This setting configures the maximum number of outstanding ACKs in Windows XP/2003/Vista/2008:
For gaming performance, recommended is 1 (disable). For pure throughput and data streaming, you can experiment with values over 2. If you try larger values, just make sure TcpAckFrequency*MTU is less than RWIN, since the sender may stop sending data if RWIN fills without an acknowledgement.
Also, find the following key (if present):
To configure the ACK interval timeout (only has effect if nagling is enabled), find the following key:
For Windows NT SP4, the TcpDelAckTicks path is:
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.
To change the checksum offloading in the Windows Registry:
TcpTimedWaitDelay (port allocation)
By default, short-lived (ephemeral) ports between 1024 and 5000 are allocated as needed by the OS. The default settings are usually sufficient under normal load. However, in some instances it may be necessary to adjust the parameters below to tweak the availability of user ports requested by an application.
If the default limits are exceeded under heavy loads, the following error may be observed "address in use: connect exception". By default (when the values are not present in the registry), ports between 1024 and 5000 are allocated, with the OS waiting 4 minutes before reclaiming ports after an application closes the TCP connection. If necessary, the following two registry values may be tweaked:
For additional tweaks and information, check some of our other related articles: