Home » Tweaks

Tweaking Your Bandwidth

8 March 2008 No Comment

Both XP and 2000 are still configured out of the box with respect to Ethernet rather than high-speed Internet connections, where latency plays a major role in throughput. Some people still use dial-up. Therefore Windows out of the box has to find a happy medium between dial-up and cable. 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.

I typically get around a 15% - 25% increase in my MB/Sec after these tweaks.

NOTE: Please, before you begin, back up your registry. Go create a restore point right now!

You never know what can happen when you play with the registry.

Determining your ISP’s MTU – (Maximum Transfer Unit) Data Packet Size

The “MaxMTU” value you should use in the Windows Registry is actually limited by your ISP’s MTU value, since all packets will be traveling through their servers. To determine the MTU of your ISP, try the following:

At a Dos Prompt (Command Prompt), type: ping -f -l [packetsize] [www.yourisp.com]

ex: ping -f -l 1472 www.optonline.com (that’s an el not a 1)

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: Make a note of this number.

Largest non-fragmented value

Your ISPs MTU

What you should use

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

(or higher)

Now let’s go check your MTU 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

NOTE: If any of the values listed here are not present in your registry then you must add this parameter to your registry.

Do this by Right clicking in the parameter’s window (right side) and select New – Dword and then Copy and Paste the values shown

below in red in the name field by selecting Modify DWORD. Don’t enter the quotes along with the values!

NOTE: Below are the values I used for my system, but please feel free to experiment with your system.

You can play with these numbers to decrease download speed and increase web page loading speed.

Just keep this number of multiple of your MTU.

By using the numbers I have here you will increase download speed. Cut it in half and you will lose some download speed

but increase webpage loading speed.

Try it on your system and see what works best for you.

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)

Editing your Web browser’s settings for faster loading of pages.

According to the HTTP specs, only a limited number of simultaneous connections are allowed, while loading pages. To increase that number, add the following entries to the Registry:

HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings

“MaxConnectionsPer1_0Server”=dword:00000020

“MaxConnectionsPerServer”=dword:00000010

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 distant servers not to reach their destination 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).

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

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces

MTU=1500 (DWORD, valid range is from 68 to MTU of network). Use the number you got from pinging your server.

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.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters]

NegativeCacheTime=0 (DWORD, default value: 0×12C (300 seconds), range: 0×0–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.

NetFailureCacheTime=0 (DWORD, default value: 0×1E (30 seconds), range: 0×0–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 0×0, this optimizing feature is disabled. DNS continues to send queries to an unresponsive network.

NegativeSOACacheTime=0 (DWORD. default value: 0×78 (120 seconds), range: 0×0–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.

Increase Bandwidth by tweaking QOS in Windows XP Pro Only

The following tweak applies only to Windows XP Professional edition.

The default system behavior is that all 100% of the 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.

Reboot…..Don’t forget to go download that file again to compare the speeds. I think you will be pleasantly surprised.

Also, this is by no means an all inclusive list of tweaks for optimizing broadband performance. You can play around with the registry for months squeezing out more and more



Leave your response!

Add your comment below, or trackback from your own site. You can also subscribe to these comments via RSS.

Be nice. Keep it clean. Stay on topic. No spam.

You can use these tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

This is a Gravatar-enabled weblog. To get your own globally-recognized-avatar, please register at Gravatar.