Tuning Windows for a broadband connection

Making your PC work best on broadband is a matter of windows?the size of an internal buffer that stores bytes and counts how many have been transferred before a receipt handshake is required. Too small a window and too much handshaking is required, taking up too much time. Too large a window and missed packets go unnoticed, requiring a timeout to occur before a ?not received? handshaking message is sent to retrieve the missing data. Getting the window size right is imperative for achieving optimal broadband data transfer.

The size of the TCP Receive Window (RWIN) should be set to match both the bandwidth of your line and a typical latency of the connection. This gives a figure that will generate one handshake packet every time all the data in the connection is received. You can find out the latency of your link by doing a PING command from a DOS command prompt: Ping -f -n 10 -I 1472 www.ucsf.edu.

Here, -f means don?t fragment packets, -n 10 means send 10 requests, -I 1472 sets the buffer size to match ethernet packets and www.ucsf.edu is just a convenient IP address. You can use any IP address you feel most likely to reflect your typical usage. This will give you a list of 10 time counts in milliseconds (see Figure 2), which should be equal: this is the worst case delay, as it?s the largest packet size. Repeat this exercise, but replace the 1472 with 12?you will get a smaller figure. Take the average of the two tests and use this as your average latency.

Multiply this by the speed of your connection. So, if the result was 150 milliseconds and you?re on a 512Kbit/s connection, multiply 512,000 times 0.15 to get the number of bits in transit. Next, divide that number by eight to get the byte count and this is your RWIN window size?in this case, 9,600 bytes. To set this, change the value in the Windows Registry, which varies according to the version of Windows. Windows 98 uses the string value DefaultRCVWindow in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD/MSTCP key, which should be set to the value in decimal. Windows 95 uses the same key name ,but wants ?DefaultRCVWindow?=dword:NNNNNNNN, where NNNNNNNN is an eight-digit hexadecimal number. Windows NT, 2000 and XP also use the eight-digit hex number, but add the DWORD value TCPWindowSize in the HKEY_LOCAL_MACHINE\ System\CurrentControlSet\Services\Tcpip\Parameters key. Take a backup of the Windows Registry before changing anything and reboot for the changes to take effect.

Windows 2000 and XP also support RFC1323, which allows a larger receive window setting and attempts to optimise it. This is enabled by the Tcp1323Opts DWORD value, created under the same key as TCPWindowSize, which can be 0 to turn it off, 1 to enable window sizing or 3 to enable window scaling and add time stamps to packets. Time stamps are useful on bad connections, as they enable the other end to make more intelligent decisions about when the link has gone bad and what needs to be retransmitted. However, they add 12 bytes to each packet?s header, so aren?t to be deployed lightly.

If you enable RF1323, you can set the Selective Acknowledgement Option DWORD value?again in the same ...Tcpip\Parameters key, to 1, which handles large window sizes better, and EnablePMTUDiscovery to 1. This enables automatic Maximum Transmission Unit sizing?the maximum size of data that can fit in a packet. Unless you have a good reason to fix this, leave it to the protocol.

Like this story? Spread the news by clicking below:

 del.icio.us     Digg this     reddit!