Mr Tweaks - Back to homepage
 
   

Shop | How to | Reg Edit Tips | Got An Error? | Mac Tips | About Us | Products Page | Tips | Cable & ADSL | News & Events | Strange Tips | Contact Us | Links | Security | Mail | Modems | Terms & Conditions

   

Cable Modem Guide

Digital Subscriber Line

Satellite Guide

Share the Internet across a home network

Why does tuning TCP Receive Window improve throughput? TCP is a reliable communication protocol. As a result, sender expects Acknowlegement (ACK) packets from receiver to make sure packets are delivered to destination and are free of errors. However, as sending one packet and waiting for ACK is rather inefficient, a window is implemented. In this scheme, receiver advertises its RWIN size during TCP connection setup and sender keeps sending as many packets as allowed by receive window of receiver. In other words, each packet sent closes the window a little and each ACK received opens it up a little again. On a high bandwidth or high delay (or both simultaneously) TCP connection, sender may transmit a number of packets before the first packet reaches the receiver. Even if the receiver were to send ACK immediately, it takes some more time for the ACK packet to get back to the sender. To optimize the throughput, the pipe must be filled at all times and to do this sender should never stall waiting for ACK.This is only possible if Receive Window is made sufficiently large. How large should the TCP Receive Window be? Receive Window should be larger than bandwidth delay product (also known as pipe capacity). For example, for 170ms delay on a 768Kbps link, RWIN = 768000 bits/sec * 0.170 sec = 130560 bits = 16320 bytes. Note that if either available bandwidth or the delay is doubled, RWIN would double as well. On LAN links the delay is very small. Therefore, a small RWIN would be sufficient. However, effect of insufficient RWIN size become particularly noticeable on WAN links. Due to relatively small default RWIN size (8KB) Windows 95, 98, NT 3.51 and NT 4.0 throughput would suffer in above 768Kbps connection during file transfer via FTP. Windows 2000 uses a more realistic 16KB default for RWIN. However, that too would need to be increased depending on pipe capacity. Well, that looks rather simple but latency (delay) is actually not constant. It varies from connection to connection and even during the lifetime of one connection as some IP packets may follow different routes and the heavy load on a router in the path may cause extra latency. Latency consists of two parts; Propagation delay and transmission delay. Propagation delay becomes significant for links established over satellites and transmission latency becomes significant when the packets must be forwarded over many routers. In addition routers usually introduce more latency for larger packets than smaller packets. Generally, heavy traffic in the pipe also increases transmission delays. To determine delay accurately we actually need to measure downstream and upstream delays separately because we receive large data packets on downstream and generate much smaller ACK packets on upstream. This measurement can be most effectively done on the sender side. However, we can make an intelligent guess on the receive side by using the PING tool to determine the round trip time for big (maximum data packet sized) packets. Windows 95/98, Windows NT 3.51/4.0 and Windows 2000 comes with a command line tool called "ping.exe". Open a command (DOS) window and enter the following line: ping -f -n 10 -l 1472 host_or_IP Use (MTU - 28) as the parameter for -l option (e.g. for ethernet use 1500-28 = 1472). See Microsoft KB article Q159211 on using PING tool to determine MTU (see More Information Section). Even though the article is targeted to Windows NT, this portion of the article is general enough to apply all Windows OS and the concept is applicable to other OS easily. In short, this parameter should be the largest value that will NOT generate "Packet needs to be fragmented but DF set." message. Large packet delay measured using ping tool is the worst case delay, so it sets the upper bound for RWIN. Most certainly normal delay will be smaller as ACK packets used in return path will be much smaller and typically delayed less. We may make a rough guess of typical delay by averaging ping times of large (as above) and small (ACK sized) packets. For ACK sized packets use 12 as -l parameter as in: ping -f -n 10 -l 12 host_or_IP Example: A 608/128Kbps DSL link with 200ms for maximum sized and 100ms for small packet delays: RWIN(max) = 608000 * 0.200 = 121600 bits = 15200 bytes. RWIN(typical) = 608000 * 0.150 = 91200 bits = 11400 bytes. IS there a Windows TCP Send Window we can tweak? There is not. In fact, the author of TCPTune has determined that not only is the Windows TCP SendWindow not tunable, windows 98 at least has problems with this send window.. which means that you may not be able to upload as fast as you can download even with a symmetric speed (SDSL) line. Information from the john navas site

 

   
[an error occurred while processing this directive]
Click Here!