(formerly ConSeal Private Desktop)
(partially derived from WRQ AtGuard)
(partially derived from WRQ AtGuard)
Navas Cable Modem/DSL Tuning GuideTM |
|
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-2001 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/>.
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] |
| Windows NT/2000
NTTCP32K.REG |
REGEDIT4
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters] |
|
| 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] |
| Windows NT/2000
NTTCP64K.REG |
REGEDIT4
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters] |
|
* 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).
Notes:
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 [email protected].) This script can also be used to restore all settings to default values (i.e., to remove the Receive Window tweak). |
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.
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:
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 |
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 |
|||||
|
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.)
Latency and packet loss can be measured with the 'ping' command. Open a Command window and type "ping remotesite" where remotesite is the domain name or IP address of the remote server (e.g., "ping www.yahoo.com"). For more information, see "How to find out what's slowing you down".
In basic terms, latency is the time needed for a round trip over the Internet between two points (e.g., your computer and remote host). Latency is usually not a problem with a proper TCP Receive Window (see "Why TCP Receive Window matters"), but high latency can adversely affect interactive applications such as on-line real-time gaming. High latency is usually caused by Internet routing and/or congestion issues. There's usually not much you can do about such issues other than complaining or even switching service providers. However, if your latency is is higher due to "interleaved mode" then it may be possible to get some improvement. See "What is 'Interleaved Mode?'"
Data is transmitted over the Internet in blocks known as packets. Packets usually reach their destination, but may be lost due to such things as network congestion. When a packet is lost, it takes a significant amount of time for: the receiver to notice that a packet has been lost; the receiver to notify the sender to resend the lost packet; and packet(s) to be retransmitted. Ideally zero, packet loss should be less than 1%; packet loss over 5% is generally considered severe. There's usually not much you can do about packet loss other than complaining or even switching service providers. There is no adjustment that you can use to decrease packet loss. However, if you are suffering from packet loss, the adverse effects may be reduced by decreasing the TCP Receive Window. See "Why TCP Receive Window matters".
Your upload speed (sending to a remote host) will be limited by your Internet connection, network path, and remote host. It may also be limited by capping (see "How the Upstream Cap can affect Downstream Speed"). It is not limited by settings you can adjust; i.e., there is no adjustment that you can use to increase upload speed.
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.yahoo.com |
(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.
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.
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, with optimum configuration of your computer (see "Increasing TCP Receive Window") 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).
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 by HTTP or FTP. The executable files in the Windows 95 download are exactly the same as the Windows 98 CD version, so the download should also work for Windows 98, notwithstanding the warning on the Microsoft web page. It may work for Windows Me as well.) 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".)
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: $37.50) by Visualware, 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:
Although downstream speeds are usually high (typically in the range of 768 Kbps to 1.5 Mbps), consumer-grade Cable or DSL service often has an upstream cap (artificial limit) of 128 Kbps, which is only about 3 times faster than a V.90 (56K) dial-up modem, and a fraction of the downstream speed.
What is not generally well-known is that the upstream cap can also affect the downstream speed -- if the upstream is saturated by uploading (e.g., sending a large PowerPoint file to the boss, or running a Napster or other public service), the downstream will drop to about the same speed. This is due to a weakness in the basic TCP Internet protocol, not Cable or DSL per se, and not the service provider.
Cable Internet is more vulnerable to this problem than DSL. Unlike DSL, where each subscriber has a dedicated connection to the head-end (DSLAM), the Cable Internet upstream path to the head-end (CMTS) is shared by all subscribers on a given cable segment. If that upstream gets saturated, which might be caused by only a relatively few subscribers, downstream speeds take a big drop for all subscribers on that segment.
As an illustrative example, consider a DOCSIS cable segment with 4 upstream channels per downstream channel, and 1000 subscribers (a recommended maximum).
- The upstream channels can be anywhere from 160 Kbps (200 kHz QPSK) to 10 Mbps (3.2 MHz QAM 16), with 800 Khz QPSK perhaps the most common in practice, giving an upstream channel capacity of 640 Kbps.
- The downstream channel can be 27 Mbps (QAM 64) or 36 Mbps (QAM 256), with 27 Mbps (QAM 64) perhaps the most common in practice.
The aggregate upstream capacity of 4 channels would be about 2.5 Mbps, as compared to downstream capacity of 27 Mbps. If the upstream saturates, the downstream rate will drop to about the same speed, a dramatic slowdown of about 90% (2.5 Mbps as compared to 27 Mbps).
Even with cable modems capped to 128 Kbps upstream, 2.5 Mbps upstream capacity can handle only 20 (2.5 Mbps / 128 Kbps) simultaneously active modems before saturation. That's generally not a problem if cable modem usage is typically (1) infrequent, (2) downstream [e.g., web surfing], and (3) interactive [e.g., fetch-use]. The system can break down if those conditions are not met.
This makes it easier to see why certain Cable Internet providers condemn continuous use of upstream (e.g., running a popular public service) as "abuse" -- each such subscriber consumes capacity normally allocated for 1000 / 20 = 50 subscribers. Worse, there's a threshold effect: If the upstream is running at (say) 80% of capacity with typical subscribers, it takes only 4 (out of 1000) heavy upstream users at 128 Kbps to drive the upstream into saturation, thereby slowing downstream to a crawl for all subscribers on that segment. (Exact numbers, of course, depend on actual channel numbers and speeds.)
For more information, see TCP Performance Implications of Network Asymmetry.
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:
If you are running Windows 95/98/Me, at a minimum you should make sure that the built in capability for File and Print Sharing can't be used against you over the Internet using one of the following methods:
| Case A: Disable File and Print Sharing You don't want to share files or printers on a local area network. (Your computer and workgroup names will still be visible, but that does not actually make you less secure.) |
|
| Case B: Disable NetBIOS over TCP/IP You want to conceal your computer and workgroup names from the Internet (even though that does not actually make you more secure), or you do want to share files or printers on a local area network using (only) NetBEUI (which is safe from the Internet, unlike TCP/IP) for File and Print Sharing. Note: Disabling NetBIOS over TCP/IP may cause connection problems with some Internet Service Providers. If you experience problems, or simply want to avoid any problems, use Case A, Case C, or Case D, which are equally secure. |
|
| Case C: Unbind TCP/IP from File and Printer
Sharing You do want to share files or printers on a local area network using (only) NetBEUI (which is safe from the Internet, unlike TCP/IP) for File and Print Sharing. (Your computer and workgroup names will still be visible, but that does not actually make you less secure.) |
|
| Case D: Set a Scope ID for File and Printer
Sharing over TCP/IP You do want to share files or printers on a local area network or over the Internet using TCP/IP for File and Print Sharing. (Your computer and workgroup names will not be visible except to other computers with the same Scope ID.) |
| See "Increasing NetBIOS Security with Scope ID". |
If you are running Windows NT/2000, security is considerably more complex than for Windows 95/98/Me. Start with:
For more information on the real risks of Microsoft Networking, see "File and Printer Sharing (NetBIOS) Fact and Fiction".
For greater security, run a "firewall" -- special software that actively works to protect you. You can run firewall software on your own computer:
| » | AnalogX PortBlocker (free, port blocking only) | |||
| » | BlackICE Defender |
|
|
|
| » | ConSeal PC Firewall (Recommended) | |||
| » | eSafe Protect Desktop | |||
| » | Internet Guard Dog |
|
|
|
| » | Internet Firewall 98 For Personal Computers | |||
| » | Internet Firewall 2000 For Personal Computers | |||
| » | LockDown 2000 (trojan scanning) | |||
| » | McAfee.com Personal Firewall
(MPF)
(Recommended) (formerly ConSeal Private Desktop) |
|
|
|
| » | NetWatcher 2000 | |||
| » | Norton Internet
Security (partially derived from WRQ AtGuard) |
|
|
|
| » | Norton Personal Firewall (partially derived from WRQ AtGuard) |
|
|
|
| » | PC Viper | |||
| » | PGP Desktop Security |
|
||
| » | SOS Best Defense | |||
| » | SPHINX Personal Firewall | |||
| » | Sybergen Secure Desktop | |||
| » | Tiny Personal Firewall (free for personal/home use; ICSA-certified technology; recommended) (new!) | |||
| » | WinRoute Pro | |||
| » | WRQ AtGuard | |||
| » | ZoneAlarm (free; recommended for those on a budget) |
If you are willing to spend more money, you can get even better protection by using a separate standalone (hardware) firewall. See "Hardware Firewalls (SOHO Routers)".
Not all firewalls are created equal (i.e., some firewalls are better than others). If you want the best possible protection, look for:
If you have children, be warned that there is a lot of dangerous and frightening material on the Internet, so it's also a good idea to install content filtering:
| » | Hardware |
|||
» SonicWALL + Content Filter List Subscription (Recommended) |
|
|||
| » | Software |
|||
| » Cyber Patrol | ||||
| » Cyber Sentinel | ||||
| » Cyber Sitter | ||||
|
|
|
|||
| » SOS Kidproof |
For real security, run a "firewall" -- special software that actively works to protect you. You can run firewall software on your own computer:
Not all firewalls are created equal (i.e., some firewalls are better than others). If you want the best possible protection, look for:
If you have children, be warned that there is a lot of dangerous and frightening material on the Internet, so it's also a good idea to install content filtering, based on either software or hardware (e.g., SonicWALL).
For real security, run a "firewall" -- special software that actively works to protect you. You can run firewall software on your own computer:
| » | DoorStop | |||
| » | NetBarrier |
|
If you are willing to spend more money, you can get even better protection by using a separate standalone (hardware) firewall. See "Hardware Firewalls (SOHO Routers)".
Not all firewalls are created equal (i.e., some firewalls are better than others). If you want the best possible protection, look for:
If you have children, be warned that there is a lot of dangerous and frightening material on the Internet, so it's also a good idea to install content filtering:
| » | Hardware |
|||
» SonicWALL + Content Filter List Subscription (Recommended) |
|
|||
| » | Software |
|||
| » Cyber Patrol |
You get the best possible external protection by using a separate standalone (hardware) firewall. (Software firewalls may still provide better protection against internal attacks; e.g., trojans, spyware.) Many of these products also include NAT (network address translation, see RFC 1631) for sharing a single Cable Modem or DSL connection (see "How to run multiple computers on Cable Modem or DSL"):
| » | Addtron ADR-E200P (inc. dial-in port, printer server) |
|
||
| Allied Telesyn | ||||
| » AT-AR220E Router | ||||
| » AT-AR320 Router (inc. secure dial-in ports) |
|
|||
| » | BeadleNet SOHO2000 | |||
| » | D-Link DI-701 Residential Gateway |
|
|
|
| » | Farallon NetLINE Broadband Gateway |
|
|
|
| » | Kingston KNR7TXD Internet Access Router | |||
| Linksys | ||||
| » BEFSR11 EtherFast 1-Port Cable/DSL Router |
|
|
||
| » BEFSR41 EtherFast 4-Port Cable/DSL Router |
|
|
||
| » BEFSR81 EtherFast 8-Port Cable/DSL Router (QoS) |
|
|
||
| » | Macsense XRouter (NAT only*) |
|
|
|
| MaxGate | ||||
| » Ugate-Plus |
|
|
||
| » Ugate-3000 |
|
|
||
| » Ugate-3200 |
|
|
||
| » | Multi-Tech ProxyServer | |||
| NETGEAR | ||||
| » Gateway Router RT311 (Recommended) |
|
|
||
| » Cable/DSL Router RT314 (Recommended) |
|
|
||
| » | Netopia Routers | |||
| NexLand | ||||
| » ISB2LAN (NAT only*; multi-session IPsec VPN pass-through) | ||||
| » ISB SOHO (NAT only*; single-session IPsec VPN pass-through) | ||||
| » ISB Processional Series (wide range of models) | ||||
| » | SMC Barricade (inc. printer server) |
|
||
| » | SonicWALL (stateful inspection; ICSA Certified; supports IPsec VPN) (Recommended) |