DSL Speed Test and Tweaks Guide
(Provided by www.dsl-speed.org)

Contents

• Quick and Easy!
• Speedup your connection
  • Before you start
  • Increasing TCP Receive Window for Microsoft Windows (95/98/Me/NT/2000/XP)
  • Why TCP Receive Window matters
  • Dealing with latency, packet loss, and/or upload speed
  • Urban Myths exposed:
    • Why tweaking TTL won't increase speed
    • Why the System.ini Tweak Doesn't Work
  • How to check your connection speed
  • How to find out what's slowing you down
  • How the Upstream Cap can affect Downstream Speed
  • Microsoft's TCP/IP retransmission bug
  • Reduce DNS errors in Windows 2000/XP (new!)
• How-to:
  • Services (servers) on dynamic IP
  • Use  DSL and dialup at the same time
  • "Bond" multiple DSL and/or dial-up connections
  • Fax over DSL
• DSL-specific issues:
  • How to fix phone problems caused by ADSL
  • DSL problems caused by your own lighting
  • Other sources of DSL interference
  • ADSL Modem Guide (DMT issue 2)
  • Other DSL Resources

Quick and Easy!

1. Before you start
2. Increasing TCP Receive Window

[Jump to Contents]

Before you start

1. Windows Socket Update - Kernel 32
2. Dial-Up Networking 1.4 Upgrade (includes general networking fixes, not just dial-up support; also applies to Windows 98)
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

A: The only Windows 95/98/Me/NT/2000/XP network setting that has any real effect on DSL or Cable Modem speed is the TCP Receive Window size, which can be controlled with the following Registry settings:

• Windows 95/98/Me: DefaultRcvWindow
• Windows NT: TcpWindowSize
• Windows 2000/XP:
  • GlobalMaxTcpWindowSize (default for all interfaces - simplest method)
  • TcpWindowSize (individual interface - overrides default)

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:

^* 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).

Important Notes:

• Reboot your system after making any change for the change to take effect!
• According to Microsoft: "Before making any modification to the Registry, be sure to make backup copies of the Registry files System.dat and User.dat. Using the Registry Editor and modifying the Registry incorrectly could cause serious problems that may require the reinstallation of Windows." See:
  • Q256419 "How to Back Up the Registry in Windows 98" (and Windows Me)
  • Q221512 "How to Manually Restore the Windows 98 Registry" (and Windows Me)
• Caching/proxy/NAT
  • If your Internet Service Provider uses caching or proxy servers to speed access, then you may not need to adjust the Receive Window.
  • If you are sharing your Internet connection with NAT, then you need to adjust the Receive Window on all computers accessing the Internet through NAT; with proxy, only the proxy server needs the adjustment. (Microsoft's Internet Connection Sharing is based on NAT.)
  • If you are using Microsoft's Internet Connection Sharing (ICS) in Windows 98 Second Edition, then you may need to change an additional Registry setting -- see Q230116 "Slow Transfer Rates with ICS and High-Bandwidth Devices". 
• MTU
  • If you ever used a tweaking program to improve the speed of dialup modem connections, then you should restore other network settings to their defaults, particularly MTU ("MaxMTU" in the Windows 95/98/Me Registry, "MTU" in the Windows NT/2000/XP Registry).
  • If you have DSL service using PPPoE, then your MTU may need to be set to a value in the range of 1400-1492. 
  • It is not necessary to make the TCP Receive Window size an exact multiple of MTU or MSS (or any other value) to avoid performance degradation due to packet fragmentation, as is commonly claimed. That is just another urban myth.
• Latency
  • If you are running Windows 98 or Windows 2000/XP and have very high latency, you may need to increase the value above 65535 to get maximum speed (e.g., to 128000 or even 256000). This does not work with Windows 95 or Windows NT.
  • Changing the size of the Receive Window will not have any effect on latency, which is what matters most for on-line gaming. There is no setting in your computer that will help on-line game play. However, if you are on Interleaved Mode DSL, you may be able to decrease latency with a switch to Fast Mode -- see What is "Interleaved Mode?"
  • 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"). See also "How to find out what's slowing you down".
• Other
  • You can delete the downloaded file once the change has been made, but it might be a good idea to save it for future reference.
  • To remove this change from your Registry, use RegEdit to delete the particular Registry value that was added (i.e., DefaultRcvWindow, TcpWindowSize, or GlobalMaxTcpWindowSize), and reboot your system. (Windows will then return to the default value.)

[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.

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.)

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:

This TCP Receive Window tweak is needed because Windows 95/98/Me/NT/2000/XP 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]

Dealing with latency, packet loss, and/or upload speed

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".

Latency

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?'"

Packet Loss

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".

Upload Speed

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.

[Jump to Contents]

Why tweaking TTL won't increase 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:

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

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.,

(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 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:

• The setting has no effect on actual memory allocation.
• The setting does not actually affect network performance in carefully controlled tests. (Anecdotal reports are mixed, and unreliable due to Internet and system variabilities, particularly the effects of caching.)
• There is no apparent evidence that there even is any such setting in Microsoft documentation.
• Windows does not allocate buffer memory for IRQ's. (Buffers are the responsibility of device drivers, which allocate them by device, not by IRQ. On the PCI bus, a single IRQ can be shared by multiple devices.)

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

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/XP, 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

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/XP 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/XP, 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):

Other good traceroute alternatives include:

• Windows
  • Sam Spade (freeware)
  • NeoTrace (shareware: $30)
• Macintosh
  • AGNetTools (commercial: $50; also Windows version)
  • Anarchie (shareware: $30)
  • IP Net Monitor (trialware: $20)
  • WhatRoute (freeware; recommended)

[Jump to Contents]

How the Upstream Cap can affect Downstream Speed

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 4 times faster than a V.90 (56K) dial-up modem (limited to about 31 Kbps upstream), 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.)

[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:

• Windows 95/98
  Q236926 "Windows 95 and Windows 98 TCP/IP May Retransmit Packets Prematurely"
• Windows NT
  Q232512 "TCP/IP May Retransmit Packets Prematurely"
  The problem is corrected in Service Pack 6. (The latest version at the time of this writing is actually Service Pack 6a, which corrects certain problems in the original Service Pack 6.)

[Jump to Contents]

Reduce DNS errors in Windows 2000/XP

Windows 2000 and Windows XP come with a "DNS Client" Service that automatically caches (temporarily saves) DNS addresses. This boosts performance by avoiding repetitive DNS lookups of the same address -- the results of a successful lookup (positive response) are saved and reused until the cache expires.

By default the DNS Client also caches negative responses (including the lack of any response from the DNS server). Unfortunately, that can prevent you from recovering from transient DNS errors for an extended period of time. If, for example, the DNS servers at your ISP are temporarily overloaded, or slow to respond due to network congestion, the DNS Client will cache the negative response. Until that cache entry expires, which can take several minutes, it won't even try to lookup that name again -- you'll just get an immediate error. That prevents you from quickly recovering from DNS errors by simply retrying, the recommended thing to do. This can lead to frustrating delays and seeming loss of connectivity problems.

The best way for the typical Internet user to deal with this issue is to disable negative caching, leaving positive caching intact. (Completely disabling the DNS Client is like throwing the baby out with the bathwater because you would then lose the benefits of positive caching.) Negative caching can be disabled by adding three Registry Values (NegativeCacheTime, NegativeSOACacheTime, and NetFailureCacheTime, all not normally present), setting them to zero. Since manual editing of the Registry is a tricky and risky business.

There is no real downside to making these changes -- just delay if you make repeated tries to an invalid Internet name. (Nevertheless, please note that you do this at your own risk, and that it's always a good idea to back up your Registry before making any change.)

To go back to Windows default behavior, simply remove the three Registry Values described above. Since manual editing of the Registry is a tricky and risky business.

[Jump to Contents]

How to use cable/DSL and dialup at the same time

Suppose you need to use Windows 95/98/Me Dial-Up Networking (DUN) to connect to your employer's network. The usual problem is that you lose the use of your Cable Modem or DSL connection during the DUN connection. The reason that happens is that DUN automatically gets higher routing priority than your Cable Modem or DSL connection because Windows 95/98/Me can only have one default route. In other words, your Cable Modem or DSL connection is still alive, but Windows 95/98/Me won't use it.

The solution to this problem is a two-step process:

1.  Prevent DUN from getting higher routing priority.

1. Set up a DUN Connection ("connectoid") for this particular purpose.
2. Right-click on this DUN connectoid and select Properties.
3. Click on the Server Types tab.
4. Un-check any unnecessary network protocols (e.g., NetBEUI, IPX/SPX).
5. Un-check Log on to network unless it's actually needed (e.g., for your employer's network).
6. Click on TCP/IP Settings.
7. Un-check Use default gateway on remote network. (This is the critical item.)
8. Click OK to close all the dialog boxes.

Now when you connect with this particular DUN connectoid, your Cable Modem or DSL connection will still work, but the DUN connection won't. To get the DUN connection working, proceed with the second step below after you have connected.

2.  Add manual route(s) for your DUN connection.

1. Connect with the DUN connectoid created in the first step above.
2. Run the command "WINIPCFG".
3. Select "PPP Adapter" in the drop-down list.
4. Note the IP Address. (Assume it's 206.170.4.214 for illustration purposes.)
5. Close WINIPCFG.
6. Suppose the IP address you want to reach through the DUN connection is 207.200.75.200 (netscape.com). To manually add that route through your PPP Adapter (206.170.4.214 in our example), run the command:

   Syntax:	ROUTE  ADD   destination     gateway
   Example:	ROUTE  ADD  207.200.75.200  206.170.4.214

7. Now traffic to the destination you just added (207.200.75.200 in this example) will go out through DUN, and traffic to the rest of the Internet will still go out through your Cable Modem or DSL connection.
8. You can add multiple manual routes. You can also use trailing 0 values with a corresponding MASK as destination wildcards; e.g.,

   Destination	Mask	Means all destinations starting with	Example
   207.200.75.0	255.255.255.0	207.200.75.	ROUTE ADD 207.200.75.0 MASK 255.255.255.0 206.170.4.214
   207.200.0.0	255.255.0.0	207.200.	ROUTE ADD 207.200.0.0 MASK 255.255.0.0 206.170.4.214

9. When you disconnect DUN your manual routes will be lost, and the IP address of your PPP Adapter will probably change from connection to connection, so this step must be repeated after each connection. 

[Jump to Contents]

How to "bond" multiple DSL and/or dial-up connections

• Nexland ISB Pro800turbo
  (load-balancing router+switch with 2 broadband ports) (new!)
• MidPoint Internet Gateway
  (load-balancing routing, not bonding)
• Vicomsoft Internet Gateway
  ("Connection Teaming" -- for more information, see "Bandwidth Aggregation, Teaming and Bonding")

Note: This author has no connection to these companies and has not tested these products.

[Jump to Contents]

How to send a fax over DSL

• FAQ: How can I send a fax from the Internet?
• Internet fax services:
  • Digital Mail
  • eFax.com
  • Faxaway
  • FaxMission
  • FaxPC
  • FaxWave
  • FaxWeb
  • GetMessage.com
  • JFAX.COM
  • MessageClick
  • onebox.com
  • Telebot
  • uReach.com
  • web2FAX

[Jump to Contents]

How to fix phone problems caused by ADSL

full rate ADSL However, enough ADSL signal can "leak" past some splitters to adversely affect some voice telephones. (The splitter originally used by Pacific Bell was a notable offender. See note below.) The common symptoms are:

• Whine, static, or buzzing on a voice call
• Rapidly falling voice volume (the result of automatic gain control being fooled by the ADSL signal)

ADSL suppliers have a bad habit of blaming the problem on your telephone, rather than the splitter. You can insist on a proper splitter, but that can be a frustrating, time consuming hassle. Fortunately, you may well be able to fix the problem yourself with an inexpensive filter that you install next to (or otherwise upstream of) the affected phone(s). Excelsus Technologies (800-457-0967 or 760-753-9108) is a good source of this kind of filter, which it calls the "Z-BLOCKER". In the USA, use the "Z-200 W / USA WALL-PHONE" if you have a wall phone; otherwise use the "Z-200 SM / USA & EUROPE", preferably located as far from the phone as possible. Notes:Notes:

• Any old filter won't do. Do yourself a favor and get one that has been designed for just this problem.
• This author has no connection to Excelsus Technologies.
• If you experience problems with the older type PacBell splitter, you can ask that it be replaced with a better device (e.g., Keptel LPF-200, Siecor/Corning Cable Systems ADSL POTS Splitter).

Where to buy a splitter:

• Prime Services Group (or call 800-771-1115, x623 or x616)
• Westell store

[Jump to Contents]

---

DSL problems caused by your own lighting 

Some DSL modems (e.g., Alcatel 1000) are overly sensitive to RFI (radio frequency interference). Lighting dimmer switches and/or electronic (non-magnetic) power supplies for halogen lighting are a common source of such interference. The result can be a degradation of DSL performance or even a complete loss of DSL sync, even when the source of the interference is not in close proximity to the DSL modem (because the interference can be not only radiated, but also conducted through building wiring). Interference is even possible when such switches and/or lights appear to be off, since some still generate interference even when turned off. e.g., overly sensitive to RFI dimmer switches halogen lighting degradation loss of DSL sync not generate interference even when turned off

If you experience DSL problems, particularly when those problems seem to be worse at certain times of the day, you can check for this possible cause by completely disconnecting all lighting dimmer switches and halogen lights. Putting the DSL modem on a power line RFI filter (included in many surge suppressors -- see "Surge/lightning suppression for cable/DSL") may or may not solve the problem.

If you do determine that a lighting dimmer switch is causing interference, you may be able to solve the problem by replacing it with a switch that generates less interference (i.e., a switch with better RFI filtering). Cheap switches may have little or no RFI filtering; better switches that normally have good RFI filtering may be defective. Switches with good filtering are made by a number of manufacturers, including:

• Leviton Manufacturing
  • MicroDim
• Lightolier Controls
  • Onset (Recommended)
• Lutron Electronics

For more information on dimmer switch RFI, see the Lutron FAQ (frequently asked question), "What is radio frequency interference (RFI)?"

See "Other sources of DSL interference" for similar problems caused by switching power "bricks" (external AC power adapters).

For general technical information on tracking down sources of RFI, see "Track and Solve Electrical Interference" by the ARRL (American Radio Relay League, Inc.).

[Jump to Contents]

---

Other sources of DSL interference 

AM radio stations

According to Nortel Networks, ADSL speeds can be cut by up to 40% by AM radio station interference, a problem that may affect up to 15% of ADSL subscribers. See "AM radio creates ADSL static".

Bridge taps

A "bridge tap" is an unconnected cable that is spliced into your telephone line, usually the remains of a connection to a different telephone subscriber. Bridge taps can cause a variety of problems. Locating and removing them can be difficult and expensive.

DAML

Digital Added Main Line (DAML) telephone line-multiplexors (used to provide more than one phone line over a single cable pair) directly interfere with ADSL and other types of modems. The symptoms with an Alcatel 1000 include ADSL drop/reconnect cycles when the analog line goes offhook, and when automated nightly C.O. line testing occurs. (See "ADSL Readiness")

Disturbers

A "disturber" is another high-speed data service (e.g., ISDN, T-1, DSL) in the same cable bundle as your DSL service. Although DSL is designed to tolerate a certain amount of disturbance, too much disturbance can cause problems, particularly when combined with other sources of interference. Common symptoms of interference from a disturber are DSL problems that occur only at certain times of the day.

MTU

The Maintenance Test Unit (MTU) is a device installed at your location, used to remotely test your phone line. Unfortunately, it can seriously interfere with data communications. Any MTU should be removed.

Power "bricks"

Old style power "bricks" (external AC power adapters) based on transformer technology are usually fine, but some poor new style power "bricks" based on switching technology generate RFI interference much like poor dimmer switches (see "DSL problems caused by your own lighting"). These new style power bricks tend to be noticeably smaller and lighter than the old style. Replacing such a switching-type power brick with a transformer-type power brick (available at electronics suppliers; e.g., Radio Shack) should solve the problem. Be sure to get the proper current capacity as well as the proper output voltage.

Unfortunately, there is not much that a DSL subscriber can do about many of these sources of interference (except as noted) other than asking the DSL provider to try to correct any problems.

[Jump to Contents]

---

ADSL Modem Guide (DMT issue 2)

Most ADSL deployments are based on Alcatel-compatible hardware. On such systems, you generally should be able to use any device that is compliant with (ANSI T1.413) DMT issue 2.

• Alcatel
  • 1000 (Ethernet)
  • Speed Touch Home (Ethernet)
    May be subject to the sync-nosurf (green light lockup) problem
  • Speed Touch PC (internal)
  • Speed Touch USB
  • Speed Touch Pro (Ethernet)
    NAT, DHCP, DNS Relay
• Allied Data Technologies
  • CopperJet 800/E (Ethernet)
    NAT, DHCP, DNS Proxy, Packet Filtering, PPPoE
  • CopperJet 800/USB
    DHCP
• ASUS
  • ADSL Modems (Ethernet, Internal)
• Aztech
  • ADSL PCI Modem (DSL300P)
  • PCI ADSL Modem (DSL700P)
  • External ADSL Modem  (DSL900E)
• Cayman
  • 3220 (Ethernet)
    NAT, DHCP
• Cisco ³
  • 827 ADSL Router (Ethernet)
    NAT, DHCP, Firewall, VPN
  • 1417 ADSL Router (Ethernet)
    NAT, DHCP, Firewall, VPN
  • SOHO 77
    NAT, DHCP, Firewall
• Efficient Networks
  • SpeedStream 3060 (PCI)
  • SpeedStream 4060 (USB)
  • SpeedStream 5260 (Ethernet)
  • SpeedStream 5660 (Ethernet)
    NAT, DHCP, DNS (ISP support of routing mode required)
• Infinilink
  • i200 Full Rate ADSL Modem PCI Card (PCI)
  • i500 Full Rate ADSL Bridge / Router (Ethernet)
• Lucent InterNetworking Systems
  • CellPipe 50A
    NAT, DHCP, Firewall
• 3Com
  • HomeConnect ADSL Modem (PCI) ^{1, 2}
  • HomeConnect ADSL Modem (Ethernet) ^{1, 2}
  • HomeConnect ADSL Modem Dual Link (USB & Ethernet) ^{1, 2}
  • Remote 810 (Ethernet) ^{1, 2, 4}
    NAT, DHCP, DNS Proxy, Packet Filtering
• Westell
  • WireSpeed DMT ADSL External Ethernet Modem (Recommended)
    Subject to the sync-nosurf (green light lockup) problem
  • WireSpeed ADSL Ethernet Proxy Router (NAT, DHCP, PPPoE, recommended)
    May be subject to the sync-nosurf (green light lockup) problem
• ZyXEL (ZyXEL on-line store)
  • Prestige 641 (Ethernet)
    NAT, DHCP, DNS Proxy, Packet Filtering, PPPoE
  • Prestige 642 (Ethernet)
    NAT, DHCP, DNS Proxy, Packet Filtering, PPPoE

Important notes:
¹ May be compatible with Alcatel, but no specific mention of Alcatel compatibility.
² Sold only through service providers, not directly to end users.
³ According to Cisco, the 677 is not compatible.
⁴ According to a report, the Remote 810 is not compatible.

[Jump to Contents]

---

Other DSL Resources

• Websites
  • ADSL Forum

Trademarks belong to their respective owners