Boost your your internet bandwidth speed of windows XP/Vista/7/8 using software and registry tricks
TCP/IP tweaks, patches & Manual registry hacks for Windows Vista/2008
Note: Most of them may work on Windows 7
For people who wants to skip the technical part and wants the optimal Internet setting download the below patch which does everything except for “gaming tweak” (mentioned at the end of the post)
http://www.speedguide.net/downloads.php
To apply the above patch save to your desktop and run as administrator (right-click -> run as administrator). Click Y when prompted to apply settings.
To apply, save to your desktop and run as administrator (right-click -> run as administrator). Click Y when prompted to apply settings.
Increase Speed of All Data Card and Modem
Windows Vista / 2008 Tweaks
Windows Vista introduces a number of new features to the TCP/IP stack, including CTCP, and TCP Window Auto-Tuning. This new implementation works much better by default than previous Windows versions with broadband internet connections, and is able to adjust the RWIN value on the fly, depending on the BDP (bandwidth-delay product). This, however, introduces some problems with older routers and restricts the user from tweaking some of the TCP/IP parameters. Still, there is always some room for improvement, and this article explains known the tweakable TCP/IP parameters.
To enter some of the commands below, you will need to run “elevated” command prompt. To do so, click the Start icon > Run > type: cmd , then click CTRL+SHIFT+ENTER. Alternatively, you can navigate to Start > All Programs > Accessories > right-click Command Prompt and choose “Run as Administrator
Check the TCP/IP state
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”.
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).
higlyrestricted: 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, many home 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, and general reduced network performance.
- auto-tuning also causes problems with older routers that do not support TCP Windows scaling.
- 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 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
The above are the M$ Knowledge based articles. To view them input the following in your browser
Example to view MS KB 83540 type in:
Compound TCP – Improve throughput
The traditional slow-start and congestion avoidance algorithms in TCP help avoid network congestion by gradually increasing the TCP window at the beginning of transfers until the TCP Receive Window boundary is reached, or packet loss occurs. For broadband internet connections that combine high TCP Window with higher latency (high BDP), these algorithms do not increase the TCP windows fast enough to fully utilize the bandwidth of the connection.
Compound TCP (CTCP) is a newer method, available in Vista and Server 2008 (there is also a hotfix available for XP/2003). CTCP increases the TCP send window more aggressively for broadband connections (with large RWIN and BDP). 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.
By default, Vista has CTCP turned off, and Server 2008 turned on. Turning this option on can significantly increase throughput.
To enable CTCP, in elevated command prompt type:
netsh int tcp set global congestionprovider=ctcp
To disable CTCP:
netsh int tcp set global congestionprovider=none
Possible options are: ctcp, none, default (restores the system default value).
Recommended setting: ctcp
It is better to use this newer generation CTCP congestion control algorithm for most broadband connections, I recommend it being turned on.
ECN Capability
ECN (Explicit Congestion Notification) 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. ECN is disabled by default in Vista, as it is possible that it may cause problems with some older routers that do not support this feature.
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
Our recommendation: disabled
RSS – Receive-side Scaling
The receive-side scaling setting enables parallelized processing of received packets on multiple processors, while avoiding packet reordering. It avoids packet reordering y separating packets into “flows”, and using a single processor for processing all the packets for a given flow. Packets are separated into flows by computing a hash value based on specific fields in each packet, and the resulting hash values are used to select a processor for processing the flow. This approach ensures that all packets belonging to a given TCP connection will be queued to the same processor, in the same order that they were received by the network adapter.
To set RSS:
netsh int tcp set global rss=enabled
Possible rss settings are: disabled, enabled, default (restores rss state to the system default).
Default state is: enabled
Recommended: enabled (if you have 2 or more processor cores and a NIC that can handle RSS)
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.
TCP 1323 Options
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\
Tcp1323Opts=1 (DWORD, entry created automatically by Windows when you run the “netsh int tcp set global autotuninglvl=…” command, set to 0 by default).
Setting this seems to have no effect, since auto-tuning uses the TCP 1323 scale factor and changes it on the fly, disregarding this setting. Additional testing may be required to determine it’s effect if auto-tuning is turned off. Setting it to 1 is best for broadband connections.
NetDMA
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.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
EnableTCPA=1 (DWORD, 1 to enable, 0 to disable NetDMA. Value not present by default in Vista)
Recommended setting is 1, a new DWORD value may need to be created if not already present in the registry.
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, default registry value 255, default 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)
TcpTimedWaitDelay (port allocation)
Short lived (ephemeral) TCP/IP ports above 1024 are allocated as needed by the OS. The default Vista values have improved from previous Windows versions, and are usually sufficient under normal load. However, in some instances under heavy load it it may be necessary to adjust the settings 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 under Vista (when the values are not presend in the registry), the OS can allocate up to 16384 ephemeral ports above port 1024, and the OS waits for 120 seconds before reclaiming ports after an application closes the TCP connection. This is a considerable improvement over older Windows versions. However, if necessary, the following registry values can be added/edited:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
MaxUserPort=65535 (DWORD, not in the registry by default. Recommended: leave at default, or use a number above 16384 up to 65535 decimal as necessary) – maximum number of ports to use. 1024 is automatically subtracted from entered value to allow for reserved ports under 1024.
TcpTimedWaitDelay=30 (DWORD, 0xffffffff in registry by default. Recommended: 30 decimal, denoting 30 seconds) – time to wait before reclaiming ports, in seconds. Default time before reclaiming ports, if value is at 0xffffffff or not present in the registry is 120 seconds. Just reducing the delay is often sufficient without changing MaxUserPort, as it allows for reusing ports more efficiently.
Ephemeral ports can be checked and changed using netsh as well.
To query the current values, in command prompt, type:
netsh int ipv4 show dynamicportrange tcp (for UDP, use the same command, replacing only “tcp” with “udp” at the end)
To set both the starting, and max user port using netsh, in elevated command prompt run:
netsh int ipv4 set dynamicportrange protocol=tcp start=1025 num=64511 (start=NNN denoting the starting port, and num=NNN denoting the number of ports)
Notes:
By default, dynamic ports are allocated between ports 49152 and 65535 (for a total of 16384 ephemeral ports).
Using netsh allows to set both the starting port and port range. Editing the Registry allows for setting the port range, and the starting port is fixed at 1025. Deleting the MaxUserPort registry entry (or setting it to a value outside the allowed range) causes the OS to revert to using the default values.
Some system processes can install port filters to block certain port ranges. If ephemeral ports run into these filtered port ranges, TCP/IP applications will be unable to bind to any ports.
QoS Reserved Bandwidth
As with Windows XP, nework adapters have a “QoS Packet Scheduler” enabled by default, which reserves 20% of bandwidth by default for QoS applications that request priority traffic. Note this only has effect in the presence of running QoS applications that request priority traffic. Registry value is undocumented for the Vista version of Windows. To customize this setting, in the Windows Registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Psched
NonBestEffortLimit=0 (DWORD, not present in the registry by default. Recommended: 0 , possible values between 0 and 100) – indicates the percentage value of reserved bandwidth for QoS applications. Set to 0 to disable.
Notes: This tweak applies only to Windows versions that have Qos Packet Scheduler enabled. It will ONLY have effect in the presense of running QoS applications.
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 disabling Nagle’s algorithm 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 witout 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.
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)
Here are Windows XP/98 Registry Tweaks and Scroll down to see Patches
1.Increase bandwidth by tweaking QoS in Windows XP Pro
The following tweak applies only to Windows XP Professional edition.
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.
The tweak desribed below helps boost priority for DNS & hostname resolution in general. What this means is, it helps web pages load faster, and has negligible effect on downloads (not counting the couple of ms gain with the host resolution at connect-time).
Applying this tweak assumes some proficiency in editing the Windows Registry using Regedit (Start > Run > type: regedit). As always, backup your Registry before making any changes so you can revert to the previous state if you don’t like the results.
2.Host Resolution Priority Tweak host name resolution priority Windows 2k/XP
First, open the Windows Registry using Regedit, and (after backing up) navigate to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\ServiceProvider
Note the following lines (all hex dwords):
Class = 008 (8) – indicates that TCP/IP is a name service provider, don’t change.
LocalPriority = 1f3 (499) – local names cache
HostsPriority = 1f4 (500) – the HOSTS file
DnsPriority = 7d0 (2000) – DNS
NetbtPriority = 7d1 (2001) – NetBT name-resolution, including WINS
What we’re aiming to do is increase the priority of the last 4 settings, while keeping their order. The valid range is from -32768 to +32767 and lower numbers mean higher priority compared to other services. What we’re aiming at is lower numbers without going to extremes, something like what’s shown below should work well:
Change the “Priority” lines to:
LocalPriority = 005 (5) – local names cache
HostsPriority = 006 (6) – the HOSTS file
DnsPriority = 007 (7) – DNS
NetbtPriority = 008 (8) – NetBT name-resolution, including WINS
Windows 9x/ME
The tweak is essentialy the same as in Windows 2000/XP, just the location in the Registry is slightly different. For a more detailed description see the Windows 2000/XP section above.
Open the Windows Registry using Regedit, and (after backing up) navigate to:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\ServiceProvider
You should see the following settings:
Class=hex:08,00,00,00
LocalPriority=hex:f3,01,00,00
HostsPriority=hex:f4,01,00,00
DnsPriority=hex:d0,07,00,00
NetbtPriority=hex:d1,07,00,00
The “priority” lines should be changed to:
LocalPriority=hex:05,00,00,00
HostsPriority=hex:06,00,00,00
DnsPriority=hex:07,00,00,00
NetbtPriority=hex:08,00,00,00
Reboot for changes to take effect.
In addition to the tweaks already covered in Win 2k/XP Registry Tweaks and More Win 2k/XP Tweaks, the Windows XP Service Pack 2 introduces a few new issues covered in the article below. Please make sure you understand what you are doing before making any changes to your Operating System. Note the information below only applies to Windows XP Service Pack 2.
3.Remove the limit on TCP connection attempts
Windws XP SP2 introduces a few new twists to TCP/IP in order to babysit users and “reduce the threat” of worms spreading fast without control. In one such attempt, the devs seem to have limited the number of possible TCP connection attempts per second to 10 (from unlimited in SP1). This argumentative feature can possibly affect server and P2P programs that need to open many outbound connections at the same time.
Rant: The forward thinking of Microsoft developers here is that you can only infect 10 new systems per second via TCP/IP ?!?… If you also consider that each of those infected computers will infect 10 others at the same rate:
second 1: 1+10 computers
second 2: 10+10*10 computers (110 new ones)
second 3: 10+100*10 computers ( 1110 new ones)
second 4: 10+1000*10 computers (11110 new ones)
….
all the way to 10*60 + 10^60 computers in a single minute (that’s a number with 60 digits, or it would far exceed Earth’s population). Even if we consider that 90% of those computers are unreachable/protected, one would still reach ALL of them within a minute.
In other words, even though it is not going to stop worm spreading, it’s going to delay it a few seconds, limit possible network congestion a bit, and limit the use of your PC to 10 connection attempts per second in the process ! I have no problem with the new default setting limiting outbound connection attempts. Still, users should have the option to easily disable or change this setting. I might be going out on a limb here, but ever since the introduction of Windows XP I can’t help thinking that I dislike all the bult-in Windows “wisardry” in a sense that the system also limits user access. That irritating trend to ease the mental load on end users is somewhat insulting, considering that Windows is to make the more “intelligent” choice instead of the end user, as well as limit their access to tuning such settings…
End of rant.
With the new implementation, if a P2P or some other network program attempts to connect to 100 sites at once, it would only be able to connect to 10 per second, so it would take it 10 seconds to reach all 100. In addition, even though the setting was registry editable in XP SP1, it is now only possible to edit by changing it directly in the system file tcpip.sys. To make matters worse, that file is in use, so you also need to be in Safe mode in order to edit it.
You only need to worry about the number of connection attempts per second if you have noticed a slowdown in network programs requiring a number of connections opened at once. You can check if you’re hitting this limit from the Event Viewer, under System – look for TCP/IP Warnings saying: “TCP/IP has reached the security limit imposed on the number of concurrent TCP connect attempts”. Keep in mind this is a cap only on incomplete outbound connect attempts per second, not total connections. Still, running servers and P2P programs can definitely be affected by this new limitation. Use the fix as you see fit.
To change or remove the limit, you can use the following program:
Event ID 4226 Patcher v2.11
- A patching program for removing or changing the limit imposed on connection attempts in SP2. The patcher has the ability to restore tcpip.sys back to the original… Still, you might want to back up tcpip.sys, use it at your own risk. The author of this patch can be reached @ http://www.lvllord.de/
4. 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 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 TCP Window in the Windows 2000 Registry is DWORD, representing number of bytes, with range from 0 to 2^30. The recommended values (in red) optimize TCP for any high speed Internet connection and work best in most cases, however if you’d like to use a custom value follow these guidelines:
For best results, the TCPWindow should be a multiple of MSS (Maximum Segment Size). MSS is generally MTU – 40, where MTU (Maximum Transmission Unit) is the largest packet size that can be transmitted. MTU is usually 1500 (1492 for PPPoE connections). To determine the MTU value of your ISP, check out the Advanced Registry Editing section of our site.
There are three places in the Windows 2000 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. TcpWindowSize can also exist under TcpipParametersInterface – if added at this location, it overrides the global setting for this particular . 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
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 TCPWindow support as described in RFC 1323. Without this parameter, the TCPWindow 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. 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 that this 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 to 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).
Patches
This Includes
1. sguide_tweak_2k.zip
Description: Generic patch for Windows XP and Windows 2000 (all versions). This patch will optimize your TCP/IP Registry settings for high speed Internet connections. To install, extract the .inf file first, then double-click (or right-click on filename and choose install from the pull-down menu) and reboot for changes to take effect.
2.sguide_tweak_2k_pppoe.zip
Description: Generic patch for Windows XP/2000 and DSL connections using PPPoE. This patch will optimize your TCP/IP Registry settings for high speed Internet connections. It is specifically designed for PPPoE DSL connections. To install, extract the .inf file first, then double-click (or right-click on filename and choose install from the pull-down menu) and reboot for changes to take effect.
3. winxp_dnscache.zip
Description: Patch Windows 2k/XP not to cache failed DNS entries. By default, 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. This patch fixes the problem by configuring the DNS client to continue sending queries to an unresponsive network. To install, save to your HD, unzip the .reg file, then double-click the filename.
Web Patches – faster loading of Web Pages
The following patch increases Web page loading speed, by doubling the number of possible concurrent open connections. For example, imagine a web page has 20 images and some text – in order for your browser to get all these files, it opens 2 or 4 concurrent connections, depending on the Web server. Increasing the number of open connections allows for faster retrieving of the data. Please note that the patch sets some values outside of the HTML specs. If you decide to install it, backup your Registry first. Changes will take effect after you reboot. Download the patch appropriate for your OS:
OS: Windows 9x/ME
OS: Windows 2K/XP/2k3
TCP OPTIMISER
Description: The TCP Optimizer is a free, easy Windows program that provides an intuitive interface for tuning and optimizing your Internet connection. Just download and run, there is no installaion required. The program makes it easy to find the best MTU and RWIN values, test latency and tweak all the important broadband related registry parameters. The Optimizer can be helpful with tuning any Internet connection type, from dialup to Gigabit+








THE DOWNLOAD LINK IS ACCESS DENIED CAN YOU FIX IT?