Cable/DSL

Navas Cable Modem/DSL Tuning GuideTM

The Screen Savers Site of the Week

Cable modem and DSL (e.g., ADSL, G.lite, IDSL, SDSL) tips on increasing speed, enhancing security, fixing problems, sharing a connection, and more.

Copyright 1999-2000 The Navas GroupSM, All Rights Reserved.
Permission is granted to copy for private non-commercial use only.

Posted as <http://cable-dsl.home.att.net/index.htm>. 

Contents

Important Notes:

Quick and Easy!

If you want to skip all the discussions and technical explanations, and just cut to the chase, most people only need to do the following to optimize and secure their cable modem or DSL connection:

  1. Before you start
  2. Increasing TCP Receive Window, Method 2
  3. Disable File and Print Sharing (Security on cable modem or DSL, Case A)

[Jump to Contents]

Before you start

If you are running Windows 95 (rather than Windows 98/Me, Windows NT/2000, or something other than Windows), the first thing you should do is update networking to the latest version by installing:

  1. Windows Socket Update - Kernel 32
  2. Dial Up Networking 1.3 Performance & Security Update (includes general networking fixes, not just dial-up support)
  3. Windows Socket 2 Update
  4. Microsoft DUN 1.3 and Winsock2 Year 2000 Update

[Jump to Contents]

Increasing TCP Receive Window for Microsoft Windows

Q: How do I get the maximum possible DSL or cable modem speed under Windows 95/98/Me/NT/2000? Should I use one of those tweaking programs?

A: The only Windows 95/98/Me/NT/2000 network setting that has any real effect on DSL or cable modem speed is the TCP Receive Window size, DefaultRcvWindow for Windows 95/98/Me, or TcpWindowSize for Windows NT/2000. Everything else commonly recommended (e.g., TTL) are urban myths that won't help. To modify your TCP Receive Window size, use one of the following two methods:

Method 1

Save the appropriate four (4) lines of text below to your Desktop in the file name indicated (or just click the accompanying link while holding down the Shift key to download the file), and then double-click on the resulting file to add the setting into your Registry. However, this does not clean out any dial-up modem "tweaks" that might interfere with cable modem/DSL speed -- if you need to do that, use Method 2 (preferred).

Normal Latency*
(e.g., normal DSL or 2-way cable)
32K Window

Windows 95/98/Me
TCPRW32K.REG

REGEDIT4

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP]
"DefaultRcvWindow"="32767"

Windows NT/2000
NTTCP32K.REG

REGEDIT4

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"TcpWindowSize"=dword:00007fff

High latency*
(e.g., poor DSL or 1-way cable)
63K Window

Windows 95/98/Me
TCPRW64K.REG

REGEDIT4

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP]
"DefaultRcvWindow"="65535"

Windows NT/2000
NTTCP64K.REG

REGEDIT4

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"TcpWindowSize"=dword:0000ffff

* Latency: Check latency with 'ping' (or 'traceroute') to a number of distant hosts and use the highest typical value. (See Important Note below under "Latency") Reasonable rough rules of thumb are that low latency is below 100 ms, and high latency is above 200 ms (with normal latency in the middle).

Method 2

Notes:

  • Now supports Windows NT (but not yet Windows 2000 or Windows Me -- use Method 1 for Windows 2000 or Windows Me).
  • 11 Dec 2000: Report received that F-Secure Anti-Virus claims the set_rwin.vbs script (below) contains a virus. This is a false positive -- the script contains no virus.

As an alternative to the fixed Registry settings in Method 1 above, a single Windows 95/98/NT script provides not only an adjustable TCP Receive Window size, but also the ICS fix (see Q230116 "Slow Transfer Rates with ICS and High-Bandwidth Devices") and the ability to clean out any dial-up modem "tweaks" that might interfere with cable modem/DSL speed (see Important Note below under "MTU").

To run this script you must have Windows Script Host/Windows Script 5.0 or higher installed. (If it is installed, you will have WSCRIPT.EXE in the WINDOWS directory with a version number of 5 or greater.)

Click  while holding down the Shift key to download set_rwin.vbs. (1.20 is the current version number. If you have problems downloading the vbs file, a zipped version is also available for download as set_rwin.zip; you must unzip the file with a utility like WinZip after downloading.) Save the downloaded file to your Desktop (and unzip if zipped); then double-click to run it. If the script does not run correctly, your Registry may be corrupted; try downloading and reinstalling Windows Script Host. (Report problems to mailto:cable-dsl@att.net?Subject=set_rwin.vbs report.)

This script can also be used to restore all settings to default values (i.e., to remove the Receive Window tweak).

Important Notes:

[Jump to Contents]

Increasing TCP Receive Window for Apple Macintosh

Caveat: The following information has not been tested by this author. USE AT YOUR OWN RISK.

TCP Receive Window can be adjusted with the "tcp_rwin_mss_multiplier" setting of the OT Advanced Tuner from Sustainable Softworks. This author suggests a starting value of 20. You may need to experiment to find your own optimum setting(s). For more information, see:

Note: This author has no connection to Sustainable Softworks.

[Jump to Contents]

Why TCP Receive Window Matters

TCP is a packet-based protocol where data is transmitted in variable-sized blocks, typically with a maximum size of 500-1500 characters (usually 1500 characters for cable modem or DSL). Two important characteristics of the TCP protocol:

Packet Acknowledgments

In order to insure delivery of each packet, the receiver must acknowledge successful receipt by sending a special acknowledgment packet to the sender. If the sender does not receive the acknowledgment packet within a certain time limit, it assumes the packet has been lost and retransmits it (up to a retransmission limit).

Receive Window

If each data packet had to be acknowledged before another could be sent, then performance could suffer due to the delay time needed for the data packet to reach the receiver plus the time needed for the acknowledgment packet to get back to the sender. To avoid this delay, the sender is allowed to keep transmitting data packets prior to receiving acknowledgments up to a maximum "window" size advertised by the receiver, normally large enough for several packets. The larger the window, the more packets that can be sent before needing an acknowledgment; however, larger windows can require more packets to be retransmitted when a transmission error occurs. Hence, the receive window size needs to be large enough to keep data flowing continuously, but not excessively large.

DefaultRcvWindow (Windows 95/98/Me) and TcpWindowSize (Windows NT/2000) have default values of about 8K bytes (increased to 16K bytes for Windows Me/2000), which is adequate for relatively slow dialup modems and for high-speed networks with low latency (e.g., less than 20 milliseconds). Increasing DefaultRcvWindow or TcpWindowSize above the default settings (e.g., to 32-63K) can substantially improve throughput on high-speed (e.g., cable modem or DSL) connections where there is higher latency (e.g., 100-200 milliseconds), as is often the case on the Internet, particularly over long network paths.

As an example, consider the case of downloading a file at 100 kilobytes per second from a remote server over a cable modem or DSL connection. The default TCP Receive Window of about 8K bytes will be consumed in only about 80 milliseconds, which is often less than the round-trip latency on the Internet. At this point the sender has to stop sending until an acknowledgment that data was received comes back from the receiver. With a TCP Receive Window of 32K bytes, the sender can continue for as long as 325 milliseconds without an acknowledgment, which should permit uninterrupted data flow even when latency is 100-200 milliseconds or more. (With a TCP Receive Window of 63K bytes, the sender can continue for as long as 650 milliseconds.)

See animations in TCP Receive Window Illustration.

The following table can be used to determine the minimum TCP Receive Window size needed for given (1) downlink speed (see "How to check your connection speed") and (2) latency:

Minimum TCP Receive Window Needed

 

 

 

 

 

 

 

 

Downlink speed in kilobits per second

500

1000

1500

2000

2500

Latency
as measured
by 'ping' in
milliseconds

50

2K

5K

7K

10K

12K

100

5K

10K

15K

20K

24K

150

7K

15K

22K

29K

37K

200

10K

20K

29K

39K

49K

250

12K

24K

37K

49K

61K

Windows 95/98/NT default

8K

Windows Me/2000 default

16K

Navas recommended setting

32-63K

This TCP Receive Window tweak is needed because Windows 95/98/Me/NT/2000 do not do a proper job of automatically adjusting the TCP Receive Window size to accommodate different network speeds and latencies. (Other operating systems may do a better job and not need this kind of tweaking; in this author's tests, for example, Red Hat Linux 6.0 performed as well without tweaking as Windows 98 with tweaking, even though Linux was running on much slower hardware.)

[Jump to Contents]

Why tweaking TTL won't increase speed

TTL stands for Time To Live, the maximum number of seconds that a packet is allowed to be on the Internet before it is destroyed as undeliverable. However, as a practical matter TTL is really the maximum number of hops that will be followed, since TTL is decreased by at least 1 on every hop, and most hops are less than 1 second (usually much less).

The purpose of TTL is to guard against impossible or erroneous routing (e.g., loops where a packet would otherwise go around and around forever); for example, given an intended route from A to E:

A -> B -> C -> D -> C -> D -> C -> D -> C -> D  ...  

In this case (looping between C and D) the TTL counter would run down to zero and expire, bringing an end to the loop:

32   31   30   29   28   27   26   25   24   23 ... 0

The objective is to have TTL large enough that packets will always reach their destinations over valid routes even with lots of hops, but not so large that excessive resources are wasted when erroneous routing (e.g., looping) is encountered.

In Windows 95 TTL defaults to 32. In almost all cases this is sufficient, since normally the number of hops will be less than 32 (usually much less). However, if and when the number of hops does exceed 32, then packets won't reach the intended destination (and communication won't be possible at all). To guard against unusual cases where the number of hops does exceed 32, default TTL was increased to 128 in Windows 98.

The bottom line is that TTL is not a parameter that increases or decreases speed. If packets are reaching the intended destination, then increasing TTL won't have any effect at all. TTL only matters when packets aren't able to reach the intended destination over a valid route; i.e., when there is no speed at all.

You can check the number of hops on a given route in Windows by using "tracert" (Microsoft-speak for "traceroute") in a command window; e.g.,

>tracert -d www.ibm.com

Tracing route to www.ibm.com [204.146.18.33]
over a maximum of 30 hops:

  1   103 ms    97 ms    96 ms  207.21.104.2
  2   103 ms    99 ms   100 ms  207.21.104.254
  3    97 ms    98 ms    98 ms  208.147.44.1
  4   102 ms    98 ms    97 ms  207.21.177.1
  5   171 ms    99 ms    96 ms  209.157.181.165
  6    99 ms    95 ms    97 ms  209.157.181.162
  7    99 ms   100 ms    99 ms  129.250.15.1
  8   100 ms    97 ms    98 ms  129.250.3.122
  9   100 ms   100 ms    98 ms  129.250.3.77
 10   102 ms   101 ms   103 ms  198.32.136.20
 11   103 ms   104 ms   101 ms  165.87.13.2
 12   175 ms   176 ms   171 ms  165.87.13.58
 13   178 ms   175 ms   174 ms  165.87.35.76
 14   178 ms   178 ms   178 ms  204.146.18.33

Trace complete.

(The trace above was performed over a dialup modem connection. The times in ms would normally be much lower on a cable modem or DSL connection.)

For more information on TTL, see RFC 791.

[Jump to Contents]

Why the System.ini Tweak Doesn't Work

The System.ini Network Card Tweak has its origins in a discussion thread entitled "Slow cable issue????"

The claim is that the tweak (IRQn=4096) improves network performance by allocating 4 megabytes of memory as a buffer for the IRQ (n) used by your network adapter. However:

While it doesn't help, the good news is that (like TTL) this setting doesn't hurt (assuming you don't screw up your SYSTEM.INI file) -- Windows just ignores settings that it doesn't recognize.

Note: This may have gotten its start as confusion over the real SYSTEM.INI settings COMnIrq and COMnBuffer, which are used to control serial port IRQ assignment and buffering (the latter of which can help serial port throughput). But these settings pertain only to the standard Microsoft serial port driver, not to network adapters.

[Jump to Contents]

How to check your connection speed

Speed test sites on the Internet (e.g., BCTEL MultiMedia Gateway) do not provide a reliable measurement of your local link speed. The reason is that no speed test from an arbitrary remote server will tell you much about anything other than that particular route at that particular time under that particular server load, all things that can and do vary widely. (Worse, some speed test sites are so badly implemented that the results are pretty much meaningless.)

To accurately measure the speed of your local link, download a large file (at least one million bytes) from a local server under light load (e.g., Internet software from your ISP in the wee hours) and time how long it takes. When all the various overheads are taken into account, your binary FTP download speed in bytes per second will be about 1/10 of the raw link speed in bits per second (e.g., about 150 KBytes/sec over 1500 Kbits/sec link; about 38 KBytes/sec over 384 Kbits/sec link), assuming optimum configuration of your computer. (See "Increasing TCP Receive Window")

If you are running Windows 98, you can continuously monitor the speed at which data is being sent and received over a network adapter (commonly used to connect a cable or DSL modem) by installing Network Monitor Agent, which is located in the Windows 98 CD directory \Tools\ResKit\NetAdmin\NetMon. Once installed, you will be able to add Network Monitor Performance items to the display in System Monitor. (Network Monitor Agent is also available for Windows 95 in the Windows 95 CD directory \Admin\NetTools\NetMon, and can also be downloaded from Microsoft, but it apparently does not include speed monitoring capabilities.) For more information see Q200910 "How to Install Network Monitor in Windows 95/98".

If you are running Windows NT/2000, you can continuously monitor the speed at which data is being sent and received over a network adapter (commonly used to connect a cable or DSL modem) with Performance Monitor. The Object to use is Network Interface. (For information on Instances, see Q154535 "Multiple Instances of Network Interface in Performance Monitor".)

[Jump to Contents]

How to find out what's slowing you down

You've increased your TCP Receive Window, but what if you're still not getting the speed you expect? (1500 Kbits/sec ADSL service is capable of downloading at a bit more than 150 KBytes/sec.) It could just be a matter of a remote server with limited capacity. But it could also be a network under-capacity problem at your ISP (the result of overselling the available capacity to too many subscribers, an all too common problem). No matter what you may have heard or read, "the Internet" is not overloaded.

The usual symptoms of network under-capacity are high latency (the time it takes a packet to cross the network path from one end to the other) and packet loss (where transmitted data is literally lost because of insufficient network capacity). High latency has an adverse effect on interactive use; e.g., real-time gaming over the Internet. Packet loss has an adverse effect on just about everything.

The best way to pinpoint the source of a network problem is to use a standard TCP/IP network tool called 'traceroute', which measures both latency and packet loss at every network "hop" between you and your destination (remote server). Windows 95/98/Me/NT/2000 comes with a free version of traceroute called "tracert". It does a pretty good job, but the output can be hard to understand if you're not into networking. (See Microsoft's Q162326 "Using TRACERT to Troubleshoot TCP/IP Problems in Windows NT" [which also applies to Windows 95/98/Me])

One of the best traceroute alternatives is VisualRoute (shareware: $30) by Datametrics Systems Corporation, available for a variety of platforms, including Windows 95/98/Me/NT/2000, Solaris, and Linux. A fully-functional 30-day demo is available for free download. It combines excellent ease of use with a high level of functionality, notably the ability to analyze the cause of network problems and display the results in English; e.g., (real example, emphasis added):

Analysis: Node 'ftp.cdrom.com' was found in 7 hops (TTL=249). But, problems starting at hop 6 in network "CRL Network Services, Inc" are causing IP packets to be dropped. Connections to HTTP port 80 are working.

Other good traceroute alternatives include:

[Jump to Contents]

Microsoft's TCP/IP retransmission bug

Microsoft has confirmed a TCP/IP retransmission bug in Windows 95, 98, and NT that can adversely affect upload (not download) throughput over "high-delay networks (for example, satellite links)." Standard cable modem or DSL service should not be affected by this bug; i.e., the fix is usually not needed. For more information see:

[Jump to Contents]

Security on cable modem or DSL for Microsoft Windows

Security on a full-time cable modem or DSL connection to the public Internet is much more important than on a temporary dial-up modem connection. The reason is that there are all too many malicious and/or dishonest people in the world that delight in using Internet conn