For tweaking the global TcpWindowSize in Windows 2000, you can use "TcpWindowSize" instead of "GlobalMaxTcpWindowSize" (see

http://support.microsoft.com/kb/263088/en-us). It's enough.

This is a fallicy: opening more connections will *not* get you higher performance; if anything, you will get worse performance; the multiple connections can
havoc with TCP's congestion control measures.
The highest TCP performance is seen using a single TCP connection.
http://www.google.com/url?sa=t&ct=res&cd=4&url=http%3A%2F%2Fwww.sigcomm.org%2Fsigcomm97%2Fpapers%2Fp102.pdf&ei=dNvYRMK3LMa4avS
4pPwH&sig2=csgWnYb9mZpXdC3Y0PVunw

Windows 2k/XP Registry Tweaks

2001.03.31 11:00 EST by Philip
Windows 2000 and XP are built on NT technology and both are generally better optimized for networking than Windows 9x and even NT4. Regardless, both XP and 2000 are still configured
with respect to Ethernet rather than high-speed Internet connections, where latency plays a major role in throughput. Here, you will find specific information on how to optimize the Windows
2000/XP Registry for Cable Modems, DSL, or any similar type of broadband Internet connection.
Customizing the Windows Registry assumes some proficiency in tuning Windows configuration files. If you don't feel comfortable editing it, please use our TCP Optimizer program, or the
Windows 2000/XP registry patches from the Downloads section of the site. both those options will add all the parameters and set all the optimal values in the Registry automatically for you.
If you'd rather make the changes yourself, or prefer to experiment with different values to fine-tune your connection, follow the directions for editing the Registry below.
Editing the Windows 2000/XP Registry
To edit the Registry, you need to use an editor, such as Regedit. As with previous Windows versions, it can be accessed from the Start Menu ( START > Run > type "Regedit" ). Note that most
of the values recommended on these pages are not present in the Registry by default and you might have to add them manually. Also, for most of the tweaks to take effect you must Reboot.
It is strongly recommended that you backup your Registry before editing. The easiest way to backup your Registry is from within the Registry Editor, just choose "Export Registry File"
from the pull-down menu.
Recommended settings for Windows 2000 / XP
Windows 2000 & XP, unlike NT supports large windows as described in RFC1323 ( the 'RcvWindow' has a maximum value of 2**30 rather than 64K), and includes some other improvements
over its predecessors you can use to speed up any TCP/IP transfers. The best settings are listed in red, the descriptions and other options are added to provide you with better understanding and
enable you to customize your settings.
All the following entries, unless otherwise noted should be placed in the Windows 2000/XP Registry under the key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
TCPWindowSize
The value of the TCP Window in the Windows 2k/XP Registry is probably the single most importan setting that will offer the most benefit to improving your internet connection. The
recommended value (in red) will optimize TCP for any high speed broadband internet connection. It will work well for most cases, however, if you'd like to use a custom value make sure to
follow these guidelines: For best results, the TCPWindow should be a multiple of MSS (Maximum Segment Size). MSS is generally MTU - 40 (20 byte TCP and 20 byte IP headers), where
MTU (Maximum Transmission Unit) is the largest packet size that can be transmitted. MTU is usually 1500 bytes (1492 for PPPoE connections). To determine the exact MTU value of your
ISP, check out the Advanced Registry Editing section of our site or use the TCP Optimizer.
There are three places in the Windows Registry where you can add the TCP Window parameter.
HKLM/SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
GlobalMaxTcpWindowSize="256960" (DWORD, number of bytes) Valid range is from MSS to 2^30. Add the value as a decimal. Note: For best results RWIN has to be a multiple of MSS
lower than 65535 times a scale factor that's a power of 2, i.e. 44 x 1460 = 64240 x 2^2 = 256960. If you choose to use a RWIN lower than 65535, you can simply make it multiple of MSS and
turn scaling off (Tcp1323Opts=0)
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
TcpWindowSize="256960" (DWORD, number of bytes) Valid range is from MSS to 2^30. Add the value as a decimal.
Note (10/20/00): Seems MS has found another bug in Windows 2000, the TCPWindowSize should be configured with the global setting (GlobalMaxTcpWindowsSize) rather than this one -
Q263088
TcpWindowSize can also exist under TcpipParametersInterface - if added at this location, it overrides the global setting for this particular NIC.
Note: For best results RWIN has to be a multiple of MSS lower than 65535 times a scale factor that's a power of 2, i.e. 44 x 1460 = 64240 x 2^2 = 256960. If you choose to use a RWIN lower
than 65535, you can simply make it multiple of MSS and turn scaling off (Tcp1323Opts=0).
Tcp1323Opts
Tcp1323Opts is a necessary setting in order to enable Large TCP Window support as described in RFC 1323. Without this parameter, the TCP Window is limited to 64K.
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Tcp1323Opts="1" (DWORD, recommended setting is 1. The possible settings are 0 - Disable RFC 1323 options, 1 - Window scaling but no Timestamp options, 3 - Window scaling and Time
stamp options.)
Note: Tcp1323Opts="3" might help in some cases where there is increased packet loss, however generally you'll achieve better throughput with Tcp1323Opts="1", since Timestamps add 12
bytes to the header of each packet.
DefaultTTL
DefaultTTL determines the time in seconds and the number of hops a packet lives (every hop reduces it by at least 1). While it does not directly affect speed, a larger value increases the
amount of time it takes for a packet to be considered lost, discarded and retransmitted. A value that's too small can cause packets to be unable to reach distant servers at all.
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
DefaultTTL="64" (DWORD, recommended setting is 64. Other settings that are widely used are 128 and 32)
EnablePMTUDiscovery
When set to 1 (True), TCP attempts to discover MTU automatically over the path to a remote host. Setting this parameter to 0 causes MTU to default to 576 which reduces overall performance
over high speed connections. Note: setting is different than our Windows 9x recommendation
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
EnablePMTUDiscovery="1" (DWORD - boolean, valid settings are 0-->False and 1-->True. Many connections perform better with this entry at 1, however, if you prefer to set your
upstream to send fixed 1500 packets, you might want to use 0 instead). When set at 1, establishing connections and initial transfer speed might slow down a bit, however you will get better
throughput if somewhere in the path large packets need to be fragmented.
EnablePMTUBHDetect
Setting this parameter to 1 (True) enables "black hole" routers to be detected, however it also increases the maximum number of retransmissions for a given segment. In most cases you'd want
to keep BHDetect at 0 (False).
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
EnablePMTUBHDetect="0" (DWORD - boolean, valid settings are 0 = False and 1 = True. Recommended setting is 0)
SackOpts
This parameter controls whether or not SACK (Selective Acknowledgement) support is enabled, as specified in RFC 2018. SACK is especially important for connections using large TCP
Window sizes.
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
SackOpts="1" (DWORD - boolean, recommended setting is 1. Possible settings are 0 = No Sack options, or 1 = Sack Option enabled).
TcpMaxDupAcks
This parameter determines the number of duplicate ACKs that must be received for the same sequence number of sent data before "fast retransmit" is triggered to resend the segment that has
been dropped in transit.
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
TcpMaxDupAcks="2" (DWORD - range 1-3, recommended setting is 2).
Additional TCP/IP Related Parameters
The additional TCP related parameters are not necessary in most cases, and you shouldn't expect any drastic improvements, however we added them for those of you who like experimenting.
You might be able to gain that last bit of performance, or customize your TCP/IP behavior even more with those. Keep in mind you should familiarize yourself with what the parameters mean
and how they affect your connection before changing their values
MTU
Setting MTU overrides the default MTU for the network interface it is added to. Note that if EnablePMTUDiscovery is set to 1, TCP will use the smaller value of this local MTU and the
"Discovered" MTU of the underlying network connection. If you'd rather use only the MTU value specified here, you'd have to disable PMTUDiscovery, which would prevent your system
from detecting the network MTU.
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces
MTU="1500" (DWORD, valid range is from 68 to MTU of network).
Note: For Windows XP PPPoE, there is an additional location for MTU that might need to be adjusted (to 1480, or up to 1492 as per the PPPoE specs), depending on the PPPoE software you
use. Check the following location in the Registry:
HKLM\SYSTEM\CurrentControlSet\Services\NdisWan\Parameters\Protocols\0
ProtocolMTU="1480"

AFD Parameters
Afd.sys is the kernel-mode driver used to support Windows Sockets applications.
DefaultReceiveWindow
The number of receive bytes that AFD buffers on a connection before imposing flow control. For some applications, a larger value here may give a sligtly better
performance at the expense of increased resource utilization. Applications can modify this value on a per-socket basis.
Registry Location:
HKLM\SYSTEM\CurrentControlSet\Services\Afd\Parameters
DefaultReceiveWindow (DWORD, not present by default. Recommended: leave blank as is, since this value limits the TCP/IP TcpWindowSize RWIN value)
DefaultSendWindow
Same as the above setting for the send side of connections.
Registry Location:
HKLM\SYSTEM\CurrentControlSet\Services\Afd\Parameters
DefaultSendWindow (DWORD, not present by default. Recommended: leave blank as is. Alternatively, you can enter a value up to the
TCP/IP TcpWindowSize RWIN setting)
Datagram Size
MS Windows supports a fast I/O path which is utilized when sending "small" datagrams (packets). The default setting for what is considered "small" datagram
is 1024 bytes; increasing this value to match your network MTU (normally 1500) can significantly improve network performance.
To adjust this parameter:
HKLM\SYSTEM\CurrentControlSet\Services\AFD\Parameters
FastSendDatagramThreshold=1500 (DWORD value, 1024 by default when not present, recommended: 1500 decimal)
Note: setting not in the current version of the TCP Optimizer.
FastCopyReceiveThreshold
When an application posts a receive with a buffer that is smaller than the current packet being buffered by Winsock, AFD can either make an additional copy of
the packet and then copy data to the application buffers directly (two-stage copy because application buffers cannot be accessed directly under the lock), or it
can lock and map application buffers and copy data once. This value represents a compromise between extra code execution for data copying, and extra code
execution in the I/O subsystem and memory manager.
To adjust this parameter:
HKLM\SYSTEM\CurrentControlSet\Services\AFD\Parameters
FastCopyReceiveThreshold=1500 (DWORD, 1024 by default when not present, recommended: 1500 decimal)
IgnorePushBitOnReceive
Setting this parameter to 1 causes Afd.sys to treat all incoming packets as though the push bit was set. We recommend leaving this at the default of 0 (disabled).
Registry Location:
HKLM\SYSTEM\CurrentControlSet\Services\AFD\Parameters
FastCopyReceiveThreshold (DWORD boolean, 0 by default when not present, recommended: don't set)
References: Technet
Web Patch
According to the HTTP specs, only limited number of simultaneous connections are allowed, while loading pages. To increase that number in Internet Explorer, you can add the following
entries to the Registry (they are not present by default). For Firefox, refer to our browser tweaks article.
HKEY_USERS.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings
"MaxConnectionsPerServer"=dword:00000010
"MaxConnectionsPer1_0Server"=dword:00000010
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
"MaxConnectionsPerServer"=dword:00000010
"MaxConnectionsPer1_0Server"=dword:00000010
Notes: Keep in mind that increasing those values exceeds the HTTP specs. Increasing them much over 10 may cause problems with some websites. While these entries might improve web
page loading considerably, they tend to strain webservers more and have no effect on throughput.
Alternatively, you can download a patch (sguide_webtweak_2k) that will add these entries for you automatically from the Downloads section of our site.
Windows 2k/XP - More Tweaks
2001.03.31 11:10 EST by Philip

You can find our main Windows 2000/XP tweaks and patches here: Windows 2k/XP Registry Tweaks
On this page, you will find additional tips and tweaks for improving your network performance and broadband experience with Windows 2k/XP.

Tweak DNS Errors Caching in Windows 2000 / XP

Windows 2000/XP has 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 2k/XP not to cache failed DNS lookups:
1. You can flush the DNS cache manually, by going to Command Prompt and typing: ipconfig /flushdns
2. You can wait for the cached lookup to expire or reboot the system...
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.
winxp_dnscache_undo.inf - patch to reverse all changes made by both the Windows 2000 and XP/2003 patches above. To install, save to your HD, then right-click on the filename and chose
"install" from the pull-down menu.
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):
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters]
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 only setting, please use the
MaxNegativeCacheTtl for Windows XP and 2003 Server 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.
Related Articles:
MS TechNet - DNS Caching, Network Prioritization and Security
TechTV - Kill DNS Errors for Faster Broadband
Microsoft - DNS Resolver Cache Service
Increase bandwidth by tweaking QoS
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.
If you'd like to change how much bandwidth is reserved for QoS (the default is 20% of the total bandwidth), do the following:
1. Make sure you're logged in as "Administrator" (not just any account with admin privileges).
2. Navigate to START>Run and type: gpedit.msc
3. Navigate to Local Computer Policy > Administrative Templates > Network > QOS Packet Scheduler
4. In the right window, double-click the limit reservable bandwidth setting
5. On the setting tab, check the enabled setting.
6. Where it says "Bandwidth limit %", change it to read 0 (or whatever percentage you want to reserve for high priority QoS data)
7. Click OK, close gpedit.msc
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.
You need to reboot for changes to take effect.
Note: This tweak applies only to The Professional version of Windows XP.
To read more about QoS and ToS/Diffserv, check the TCP Optimizer documentation, or refer to Technet/MSDN.
References:
Technet: QoS Tools and Settings
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 dafault 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:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{NIC-id}
There will be multiple NIC interfaces listed there, for example: {1660430C-B14A-4AC2-8F83-B653E83E8297}. Find the correct one with your IP address listed. Under this {NIC-id} key,
create a new DWORD value:
TcpAckFrequency=1 (DWORD value, 1=disable, 2=default, 2-n=send ACKs if outstanding ACKs before timed interval. Setting not present by default).
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):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters
Add a new DWORD value:
TCPNoDelay=1 (DWORD value, 0 to enable Nagle's algorithm, 1 to disable, not present by default)
To configure the ACK interval timeout (only has effect if nagling is enabled), find the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{NIC-id}
TcpDelAckTicks=0 (DWORD value, default=2, 0=disable nagling, 1-6=100-600 ms). Note you can also set this to 1 to reduce the nagle effect from the default of 200ms without disabling it.
For Windows NT SP4, the TcpDelAckTicks path is:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\{NIC-id}\Parameters\Tcpip
TcpDelAckTicks=0 (Default=2, 0=disables nagling, 1-6=100-600 ms)
Notes:
Reportedly, the above gaming tweak (disabling nagle's algorithm) can reduce WoW (World of Warcraft) latency by almost half!
XP/2003 needs hotfix or SP2 for it to work (MS KB 815230)
Vista needs hotfix or SP1 for it to work (MS KB 935458)
References:
RFC 2581
Wikipedia: Nagle's algorithm
Technet: TCPNoDelay
MS KB 311833
MS KB 321098
MS KB 321169
Smallvoid: nagle algorithm
Checksum Offloading
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 in the Windows Registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
DisableTaskOffload=0 (DWORD value, 0=enable offload, 1=disable offload, default not set)
Recommended: leave at default unless experiencing problems.
Note: Checksum offloading should not be activated together with the Windows Firewall.
Also see: MS KB 888750, MS KB 904946, MS KB 936702
Advanced Tweaking
2001.03.31 11:21 EST by Philip

This page is provided as a supplement of our Registry Tweaks articles. Here you will find more advanced information on implementing the same tweaks,
methods for determining MTU, BDP and RWIN calculations, as well as other suplemental relevant information.
Determining your ISP's MTU
The TCP packet size, or the Windows Registry "MaxMTU" value you should use is limited by your ISP's MTU value, since all packets will be traveling through their equipment. To determine
the MTU of your ISP, try the following:
In Dos Prompt(Command Prompt), type:
ping -f -l [packetsize] [www.yourisp.com] where [packetsize] is the amount of data you want to send ( between 0 and 1500 bytes ) and [www.yourisp.com] is your ISP's URL (you can also
use your gateway, or any server your connection always passes through instead of your ISP's URL).
The largest value that does not give you the error "Packet needs to be fragmented, but DF set" will be your ISP's MTU - 28 (excluding the IP [20 bytes] and ICMP [8 bytes] headers). Use the
following table to interpret the number you received and determine your ISPs MTU:

Largest non- Your ISPs What you should use

fragmented value MTU
1472 1500 use 1500 (1472+28=1500) - Ethernet
1468 1496 1496 - the Ethernet standards actually call for using 1496, although 1500 is most often used for simplicity
1464 1492 1492, the Largest PPPoE MTU
1452 1480 1480, Windows XP PPPoE MTU
548 576 Check your Registry settings, your MTU might be the limiting factor if set to a small number.
(or higher)

Note: All this can be also determined automatically by using our SG TCP Optimizer program, freely available for download in the Dwonloads area of the site.
Finding the right "000n" Folder in Windows 9x
If you have multiple devices that use TCP/IP, you will have multiple "000n" folders in the Registry, under HKLM\System\CurrentControlSet\Services\Class\Net\Trans
If you add the MaxMTU value to all "000n" folders with "TCP/IP" to the DriverDesc setting, chances are you will slow down your dial-up modem connection a bit ( since its optimal
MaxMTU is still 576, rather than 1500 ).
In order to determine which is the right one for entering the MaxMTU value, you can use any one of the following methods:
1. Open Regedit, and navigate to HKLM\System\CurrentControlSet\Services\Class\Net\Trans\000n\Ndi You can modify the "HelpText" value to be any text value you wish. If you give each
000n folder a unique "HelpText" value, you can then distinguish between them all when you go to Network Properties and check the Description field for each TCP/IP binding.
2. Right-click on "Network Neighborhood" and choose "Properties". Find TCP/IP that's bound to the NIC you use with the Cable Modem/DSL. If it has a static IP address, you can look for
that under
HKLM\System\CurrentControlSet\Services\Class\Net\Trans\000n
When you look in the right "000n" folder you will find a string value called "IPAddress" with the same IP assigned to it. At this point, you can add MaxMTU only to that folder. Note: If you
have multiple NICs bound to TCP/IP, you might want to add MaxMTU to them as well, that way your LAN will benefit from the tweaks too.
3. You could also delete all but one adapter that uses TCP/IP from "Control Panel > Network". Note that before doing that, you should write down the settings of these adapters and the TCP/IP
they bind to, since you will have to re-enter them later. Once you've deleted the unnecessary adapters, reboot and you will be left only with one "000n" folder ( that has "TCP/IP" assigned to
DriverDesc ) in your Registry. At this point, add the MaxMTU to this folder and re-add the adapters you erased in the previous step.
Internet Connection Sharing in Windows 98SE
Seems with the introduction of Internet Connection Sharing (built-in NAT solution in Win98SE), Microsoft added another entry for MTU. You will need to change this, in order to optimize
throughput:
HKLM\System\CurrentControlSet\Services\ICSharing\Settings\General\ "internetMTU"=1500
Bandwidth*Delay Product and the TCP Receive Window
The Bandwidth*Delay product (BDP) determines the maximum amount of data that can be in transit in the network. It is directly related to the Maximum TCP
Receive Window (RWIN) value that should be used when tweaking your internet connection. Throughput can not exceed the BDP and the TCP Receive
Window (RWIN) needs to be large enough to fit the BDP.
With that in mind, here is the BDP formula:
BDP = bandwidth * latency
or,
BDP(bytes) = total_available_bandwidth(KBytes/sec) * max_round_trip_time(ms)
Essentially, the BDP depends on the maximum available bandwidth multiplied by the latency/delay/ping value.
RWIN (the TCP Receive Window) is the TCP buffer that determines how much data can be in transit in the network, just as the BDP. It should be big enough to
accomodate BDP. In addition, the TCP specs, and related RFCs also introduce a few notable considerations for calculating an optimal RWIN value summarized
below:
1. Early TCP specs (before RFC 1323) allowed for only 16 bits in headers for the RWIN value, limiting it to 16KB (65535).
2. Related RFCs recommend the value to be multiple of the MSS (packet size without headers, usually MTU - 40 bytes of TCP and IP headers).
3. Above 65535 (The maximum possible unscaled RWIN value), the TCP Window is calculated by multiplying the unscaled RWIN by a scale factor that's
multiple of 2. This scale factor is stored in the TCP Options RFC1323 header extension.
4. RWIN should be calculated based on the maximum anticipated (not current) latency.
5. Even with large RWIN values, the unscaled RWIN should remain a high number for backwards compatability with legacy routers.
6. A RWIN value that's too large may perform poorly in the presense of packet loss. Even though it does not "cause" packet loss, the older congestion control
TCP algorithms slow down recovery. Those algorithms, however have been superceeded by CTCP in Windows Vista/2008 (and 2003/XP64 with hotfixes).
With all those points in mind, calculating the optimal RWIN value is a bit more involved than just plugging any number in the Windows Registry. Below is a
good way to accomplish this in 3 steps:
1. Determine MSS (displayed by the SG TCP Analyzer), maximum anticipated latency and advertised maximum bandwidth.
(for example, 1460 MSS, 300ms max latency, 6Mbit/s max bandwidth).

2. Find the optimal unscaled RWIN value (largest even multiple of MSS less than 65535):
65535 / 1460 (MSS) = 44.9
round down to even number = 44
44 * 1460 (MSS) = 64240 (this is the optimal unscaled RWIN value)

3. Multiply the unscaled RWIN by 2 until the result is close to/larger than the BDP.
Our BDP for 6Mbps @ 300 latency is:
6000 kbps * 300ms = 1800000 / 8 = 225000 bytes
64240 (unscaled RWIN) * 2 * 2 ... = 256960 (number larger than BDP, this is the optimal RWIN)
Note that the above calculations are already implemented in both the TCP Analyzer and the TCP Optimizer. The BDP can also be easily determined using our
online BDP Calculator.
UDP Packet Size
UDP over IP has a total header length of 32 bytes (12 bytes for UDP, and 20 bytes for IP).
To change the UDP packet size, in the Windows Registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters
MaximumUdpPacketSize=512 (DWORD, default value is 1280 bytes. Must be a number between 512 and 16384)
Recommended values: between 512 and 1468.
Note: When you configure the UDP packet size, remember that UDP packets must travel through different devices that may not support large UDP packets.
Some network equipment cannot handle packets larger than 1468 bytes, particularly under heavy load.
Windows 2003 TCP/IP parameters
Windows 2003 Server-specific broadband related registry settings
2007.12.12 12:12 EST by Philip

Windows 2003 SP1 and SP2/R2 (as well as Vista/2008) introduce some interesting new NDIS 6.0 hardware features to improve network performance. The
parameters discussed below intended as an addition to our recommended XP/2003 network settings. Most of those parameters are new, introduced with the
"Scalable Networking Pack".
TCP Chimney Offload
TCP Chimney Offload is an extesion of NDIS 5 offloading, and makes it possible for network cards to replace the Windows TCP stack with their own
implementation. The TCP connection state, once established is transfered to the NIC miniport driver, which then completely handles the traffic between teh
application and the remote host. In essence, the NIC miniport driver provides a "chimney" from the top to the bottom of the TCP stack.
TCP Chimney offload improves the performance of long-lived connections with large-sized payloads, such as data streaming and large file transfers.
To enable Chimney Offload, in command prompt:
netsh interface tcp set global chimney=enabled
Or, in the Windows Registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
EnableTCPChimney=1 (1=enabled, 0=disabled)
Notes: TCP Chimney offload is disabled automatically in the presense of a software firewall (Windows Firewall), ICS (Internet Connection Sharing), IPsec,
IPNAT.
Receive-side Scaling
Enables use of multiple CPUs to handle received packets (where the NIC spreads the load to available CPUs).
To enable/disable RSS, in command prompt:
netsh interface tcp set global rss=enabled
In the Windows Registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
EnableRSS=1 (1=enabled, 0=disabled)
Notes:
RSS should not be activated if using ICS (Internet Connection Sharing), or ISA server. More info: MS KB 927695, MS KB 927168
TCP Acceleration (TCPA)
To enable TCP Offloading support (TCPA), in the Windows Registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
EnableTCPA=1 (1=enabled, 0=disabled).
Notes: TCPA should not be activated if ISA server is enabled.
Also see: MS KB 947773
Network Direct Memory Access (NetDMA)
NetDMA minimizes the CPU processing needed to move packets between memory buffers. It has some hardware requirements, such as INtel I/O Acceleration
Technology (Intel I/OAT) available with Xeon processors to function. NetDMA will not work together with "TCP Chimney Offload" and requires "Receive-
side Scaling". Windows chooses NetDMA if it detects that both NetDMA and TCP Chimney Offload is supported.
NetDMA will be disabled automatically in the presense of a software firewall, ICS, IPsec, IPNAT.
Compound TCP (CTCP)
Compound TCP is a newer congestion-control algorithm available in Vista, 2008 Server, and via hotfix in 2003 Server, or even XP (64-bit). CTCP is a
considerable improvement over the traditional slow-start and congestion-avoidance methods, especially over high-speed internet connections. CTCP attempts to
maximize throughput by monitoring delay variations and packet loss. It also ensures that its behavior does not impact other TCP connections negatively. We
highly recommend enabling this setting.
For Windows 2003/XP, to set CTCP, in the Windows Registry, navigate to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
TCPCongestionControl=1 (DWORD value, 1=enable, 0=disable)
Recommended: enabled
See also:
MS KB949316 - Hotfix for Windows 2003 Server and XP (64-bit).
MS KB947775 - Hotfix for Windows 2003
Checksum Offloading
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 in the Windows Registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
DisableTaskOffload=0 (DWORD value, 0=enable offload, 1=disable offload, default not set)
Recommended: leave at default unless experiencing problems.
Note: Checksum offloading should not be activated together with the Windows Firewall.
Also see: MS KB 888750, MS KB 904946, MS KB 936702
References
MS KB 912222 - The Microsoft Windows Server 2003 Scalable Networking Pack release
MS Whitepaper - Introduction to the Windows Server 2003 Scalable Networking Pack
The Cable Guy - Scalable Networking Pack
LAN Tweaking
2005.03.15 13:02 EST by Philip

The following tweaks are focused towards increasing local network performance under Windows XP/2k/2k3 Server. They can be used in addition to all the
broadband tweaks, if you are on a LAN. All information in this article presumes some proficiency in editing the Windows Registry. Even though we extensively
test all our tweaking recommendations, use of the below information is at your own risk.
Disable Network Task Scheduler
(LAN Browsing Speedup)
This tweak disables searching networked computers for scheduled tasks. It reduces the long wait when opening network folders. To apply this tweak, find the
following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RemoteComputer\NameSpace\
and delete this key:
{D6277990-4C6A-11CF-8D87-00AA0060F5BF}
Here are registry files you can merge to directly apply/undo this tweak:

sg_lan_speedup.reg

undo_sg_lan_speedup.reg
Note: You might want to export the key before deleting, then to revert the changes, simply merge your exported reg file.
Removing the second sub-key in HKLM\.....\NameSpace that looks like: {2227A280-3AEA-1069-A2DE-08002B30309D} disables checking for network printers.
Increase Request Buffer Size
(reduce network delay)
In higher latency Network environments, delays may be encountered with the default request buffer size (4356 decimal). The range of this parameter is 1024 -
65535 bytes. Testing has shown that, in most standard Ethernet environments, 16384 (decimal) is a better choice, if memory is available. This tweak only
applies to LANs, and helps with slow browsing of large directories.
To change this setting, edit:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters and Add Value name SizReqBuf as a type REG_DWORD,
increase its (decimal) value to 16384 or even higher and restart the computer for changes to take effect.
Here is the MS KB Article 320829 that describes the procedure as well.
Increase Network Redirector Buffers
(better network performance)
If you increase the number of network redirector buffers it may considerably increase your network throughput. Each extra execution thread that you configure
will take 1K of additional nonpaged pool memory, but only if your applications actually use them.
To configure additional buffers and threads, edit: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanWorkstation\Parameters Modify or
Add Value of type REG_DWORD for:
MaxCmds=dword:00000064 - range is 0 - 255 and the default value is 15. Set to a higher number, try 64 for starters.
MaxThreads=dword:00000064 - set to the same value as MaxCmds.
MaxCollectionCount in the same key is a DWORD buffer for character-mode named pipes writes. You might want to increase it from te default 16 as well, its'
range is 0 - 65535.
No shares in my My Network Places
Speed up Windows Explorer and network browsing by stopping automatic shares in "My Network Places"
By default, Windows 2k/XP/2k3 tries to read icon information from shortcuts in the "My Network Places" folder, accessing remote files on the network, and
causing a very slow system response. Every time you open a file in a remote shared folder, or a file via a UNC name, Windows will automatically add another
shortcut to "My Netowork Places", making the problem worse with time. To resolve this:
Navigate to:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer and add a new DWORD value:
NoRecentDocsNetHood=1 (set it to 1 to disable remote shared folders from being added to Network Places).
Depending on your OS, it might also be possible to modify this by accessing the Group Policy Object Editor. To use this method to achieve the same effect:
- Go to Start > Run > type: gpedit.msc
- In the GPOE, navigate to: User Configuration > Administrative Templates > Desktop > Enable "Do not add shares of recently opened documents to My
Netowrk Places"
Notes:
The above might also work by adding the same key to the HKLM Registry hive here, but we have not tested it:
HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoRecentDocsNetHood=1 . The MS Group Policy Editor adds the entry
to HKEY_CURRENT_USER.
For additional info, see: MS TechNet - NoRecentDocsNetHood