Navas 28800-56K Modem FAQTM
(Answers to Frequently Asked Questions)
GroupSM, All Rights Reserved.
Permission is granted to copy for private non-commercial use only.
Send mirror and commercial license inquiries to John Navas.
Posted as <http://modemfaq.navasgroup.com/faq_a.htm>.
does not require registration; and does not use browser "cookies."
Copies of this (or other Web) document may be obtained by email from a
or "Agora" (e.g., firstname.lastname@example.org,
server in hypertext (HTML) or plain text format. For more information,
send an email message to the server with a body of "help". Another alternative
The author has no present connection with any modem company (other than
as a customer), and does not endorse the products of any company. This
information was compiled by the author and is provided as a public service.
Neither the author nor any organization mentioned herein are responsible
for any errors or omissions, or for any consequential problems that might
result. USE AT YOUR OWN RISK.
The author does not have the time to give individual technical support,
so please do not email requests for assistance. Instead, post them
to Usenet. Thank you.
Email comments and suggestions to John Navas
Why don't I get 28800 bps (or more) on my connections?
(If you see a connection speed of 38400, 57600, or 115200, don't be fooled
-- that is the serial port speed between your computer and your modem,
the speed between your modem and the remote modem. To report the modem-to-modem
speed, your modem probably needs a different initialization string. Consult
Note: Reported initial connect speeds won't necessarily be
dependable or even comparable from modem to modem or location to location.
The reason is that V.34 modems can (and often do) speed shift up and down
after the initial connection, and do so in a manner that is dependent on
the particular connection as well as the particular equipment (including
firmware versions) at each end. (See "What
are "fall-back" and "fall-forward"?") Some modems connect at a more
conservative speed and then quickly upshift as conditions allow; other
modems connect at a more aggressive speed only to quickly downshift (or
worse, lose performance due to excessive errors). Another problem is that
software may report the receive speed for certain modems and the transmit
speed for other modems, which can be substantially different. (See "What
are split/asymmetric speeds?") Unfortunately, it is not possible to
monitor the actual modem speed during the connection for most modems. Regardless,
only thing that really counts is net throughput, which can be measured
by many communications applications.
If you consistently connect at 26400 or above, there may not be much
that you can do to go faster -- it's simply not possible to achieve the
highest V.34 speeds on many phone circuits. (This is not false modem advertising
-- 28800 modems are designed to wring as much speed out of the actual real-world
connection as possible, and 28800 or higher speed is only possible on a
If you consistently connect at lower speeds (e.g., 24000 or even
21600), there may still not be much that you can do, but you can at least
try the following:
Those with a technical bent may be interested in the telecom troubleshooting
information posted in the Technical
Bulletins by Mike Sandman, who sells a variety of hard-to-find telecom
tools, parts, and test equipment. Note: This author cannot vouch
for the accuracy of that information.
Make sure that your serial port is locked at 38400 or higher (57600 recommended).
This is usually set within your comm application, not the
Windows Control Panel (see "How do I set a
speed greater than 19200 bps in Windows?").
Watch out for heat. Some modems work better cold than hot, and vice
versa. Generally speaking it is a good idea to make sure that the modem
does not get too hot.
With a PC Card (PCMCIA) modem in a laptop computer, try disconnecting the
computer from AC power and running on battery alone.
Try connecting to known good 28800 numbers (e.g., Hayes at 800-"US-HAYES;
Multi-Tech at 800/392-2432; USR at 847/982-5092). This will at least tell
you whether the problem is at your end or the other end of the connection.
(The USR number is particularly useful, because you can get an on-line
reading of connection quality from a USR BBS command.)
Watch out for dialin numbers that are being forwarded to a distant location.
It's a "dirty little secret" that many BBS (bulletin board systems) and
ISP (Internet service providers) use Call Forwarding to extend their local
calling areas. (Where location A to location C is a toll call, and an intermediate
location B is local to both A and C, Call Forwarding from B to C effectively
makes A to C a local call.) Although this can work fairly well at lower
speeds (e.g., 14400), the extra connection hop(s) can degrade the
signal enough to limit higher speeds (even as compared to a direct long
distance call). A local number does not necessarily mean a local call.
If you have your modem connected to the phone line through a surge suppresser,
try it without the surge suppresser. Many surge suppressers can interfere
with modem communications. (In general, this author does not
think that cheap phone line surge suppressers are a good idea. If you want/need
surge suppression, see "Where can I get a good
telephone line surge suppressor?")
If possible, test for premises problems by disconnecting all your
premises wiring (and equipment) from the incoming telco terminating block,
and hooking your modem directly to it. If your connections are better,
you have a premises problem that you may be able to isolate and fix. Premises
problems (faulty wiring and/or equipment like cheap phones and fax machines,
and even other modems) are a frequent cause of connection problems.
If you need to fix your premises wiring, you may be able to get help at
Home Page". Note: This author cannot vouch for the accuracy of
If that doesn't help, listen carefully to the quality of your voice connections.
Note that you must dial a known quiet number, since many otherwise good
phone lines exhibit excessive noise until you actually connect. (Dialing
a single digit is not enough.) After you connect, if you
hear more than very faint hiss and/or hum, then you probably have a line
While a quiet line is important, there are other line problems that can
reduce your speed: bandwidth (frequency response), distortion, etc.
It is difficult to test for these problems without proper test equipment,
but it's still a good idea to listen carefully for audible problems, particularly
if you can find a number that will send you test tones.
You may be able to get your phone company to improve the quality of your
line. Since phone companies are often reluctant or even unwilling to work
on data problems, it may help to report that you are also having fax problems.
Or you can try asking for a data or fax "specialist." Ideally you want
the service technician to bring the right kind of test equipment, a sophisticated
line or transmission test set, not just the normal basic tester. It may
also help to ask for a BERT (bit error rate tester) or "data test set."
Sometimes switching to a different cable pair from the CO (central office)
will help. In extreme cases the author has resorted to ordering a new line,
making sure that it is good when installed, and then canceling the old
You may be told that you need a special "data" line, more properly called
a "conditioned" circuit, which is considerably more expensive than a standard
"voice-grade" circuit. Don't waste your money. All you need is a
good quality "voice-grade" circuit.
A final note: Common add-on noise filters will not help
-- they are the modem equivalent of snake oil. Your 28800 modem already
has all the filtering it can use. A common add-on filter will do nothing
at best, and it may well make things worse.
Why am I getting CRC errors (overruns)?
CRC errors (e.g., as reported by ZMODEM
or Windows 95/98 System Monitor),
particularly when downloading, are usually a sign of overrun (incoming
data that is lost because the computer is unable to process it in time).
Overrun can result from a variety of causes. The following are suggestions
on how to avoid CRC/overrun errors (particularly in Windows 3.1):
Use a 16550A UART. (See "Do I need a 16550
UART? What is a UART?" and "Why does
Windows lock up when I access my modem?") Note that most, but not all,
internal modems have a 16550.
Use hardware flow control, and make sure it is working properly. This applies
both to your modem and to your comm software. If you experience overrun
while uploading, then you almost certainly have a flow control problem
in your comm software and/or modem configuration.
If you are running anything other than the standard Windows VGA driver,
switch to the standard VGA driver and see if that affects your problems
-- certain video drivers are known to interfere with communications. (See
"Where can I get updated video drivers?")
If you determine that your video driver is causing overruns:
If your video card uses a recent S3 chipset
(e.g., 864, 964, or 968), there may be an option in the video driver
to set "Bus-throttle=On" (usually Off by default) in
the [display] section of SYSTEM.INI, which may well solve the
problem. ("Bus-throttle=On" may slightly reduce speed as measured
by benchmarks, but the difference will probably not be noticeable in the
real world.) Contact the manufacturer of your video card. (Note: Generic
S3 video drivers are available from S3. Unfortunately, they do not
work on all S3-based video cards.)
If your video card is a PCI type and made by Matrox,
try adding PCIChipSet=1 to the [MGA.DRV] section of SYSTEM.INI,
which may well solve the problem. (Add the section header if it does not
already exist.) If it does solve the problem, check with Matrox for an
updated video driver.
If you are running Windows 95/98, you may be able to work around the problem
by using Start | Settings | Control Panel | System | Performance | Graphics
to turn down the amount of Hardware Acceleration.
If possible, use 32-bit disk access under standard Windows, as well as
32-bit File Access under Windows for Workgroups. If not, be sure you have
a current version of a quality BIOS and/or disk driver.
Watch out for poorly-written firmware and/or device drivers for local bus
IDE interfaces, particularly in multi-sector mode. Obtain the latest versions.
(See "Where can I get updated disk/SCSI drivers?")
You may be able to alleviate an overrun problem by switching modes and/or
reducing the number of sectors per transfer.
Are you using a SCSI drive? Certain SCSI drivers can cause problems. Obtain
the latest versions. (See "Where can I get
updated disk/SCSI drivers?")
Disable write caching on your download disk drive. (Read caching should
With the current SMARTDRV (i.e., standard Windows, or Windows for
Wordgroups without 32-bit File Access), the /X parameter disables
all write caching. You can also disable write caching on individual drives.
"SMARTDrive Drive Letter Parameters Should Not Contain a Colon")
With 32-bit File Access under Windows for Workgroups, put the following
in the [386Enh] section of your SYSTEM.INI file:
where <drives> is a drive letter string; e.g., ForceLazyOff=C
for drive C only, or ForceLazyOff=CD for drives C and D. (See
to Disable Write Caching for the 32-Bit File System")
If you are using Procomm Plus for Windows
2.xx, set "DropRTSAroundDiskWrites=1" in your PW2.INI file. (This
won't help if you cache writes.)
Beware of TSRs, especially network TSRs. Try booting your system as clean
as possible to see if that helps.
Watch out for certain memory managers; e.g., the use of QEMM "Stealth"
may cause problems.
Put your modem on COM2 if possible, rather than COM1, especially if you
are using a serial mouse, because COM2 has higher interrupt priority than
COM1. Even better is to use a "high" IRQ (2/9, 10-12) which has higher
interrupt priority than either COM1 or COM2. (See "Where
can I get a 16550 UART?")
Under Windows, put the following in the [386Enh] section of your
where n is the number of your modem COM port (e.g., COM2FIFO=1
and COM2Buffer=1024). The COMnFIFO statement won't help
until you get a 16550A UART, but it won't hurt in the meantime.
Note: The only legal values for COMnFIFO are 0 and 1. (See "Windows
Support of the 16550 UART")
Do not use Microsoft's PC speaker
sound driver! Get a cheap sound card instead.
The Creative Labs Sound
Blaster 16/AWE 32 driver bundled with the original release of Windows
95 can cause CRC errors, and should be replaced with an updated
Watch out for an IRQ conflict. (You normally cannot use both COM1 and COM3,
or COM2 and COM4, at the same time.)
On a portable or "green" machine, you should also try disabling the power
management features, which can sometimes "kick in" and interfere with data
Disable any screen savers, which can interfere with data communications.
Don't run your serial port any faster than necessary. Marketing hype notwithstanding,
rarely any need to go faster than 38.4 Kbps with a 14.4 Kbps modem, or
57.6 Kbps with a 28.8 Kbps modem. Caveat: With an acknowledgment protocol
(e.g., XMODEM), as opposed to a streaming protocol (e.g.,ZMODEM),
a higher serial port speed can improve the response time. (See "Measurement
of DTE Rate Latency")
Try a third-party replacement for COMM.DRV. (See What
about third-party comm drivers for Windows?)
Switch to Windows for Workgroups or Windows 95/98, which have a better
serial architecture than standard Windows 3.x.
With a 16550 UART (See "Do I need a 16550
UART? What is a UART?") under regular Windows and a third-party comm
driver (e.g., WFXCOMM.DRV)
or Windows for Workgroups or Windows 95/98, try dropping the receive FIFO
trigger level. For example, where n is the number of your modem COM port:
WFXCOMM.DRV (default 14): ComnRXSize=8 (e.g., Com1RXSize=8).
Windows for Workgroups (default 8): COMnRxTRIGGER=4 (e.g.,COM1RxTRIGGER=4).
Legal receive FIFO trigger values are 14, 8, 4, and 1. The normal recommended
value is 8. You should not go down to 1 unless you are really desperate.
Why is my modem getting NO DIAL TONE?
The most obvious cause is that you've neglected to plug your telephone
line into your modem. Double check to make sure. Or the telephone cable
may be bad -- test it on a regular telephone.
A common problem is plugging your telephone line into the wrong jack
on your modem. Many modems have two jacks, one for the telephone line
and one for a telephone handset. On some of these modems (e.g.,
USRobotics), you won't be able to get a dial tone or otherwise use the
modem if you plug the telephone line into the telephone handset jack. Double
check to make sure.
Another common problem is that some other device on the same telephone
line (e.g., a telephone answering machine) is off-hook. Double check
to make sure that all other devices are on-hook.
There may be a problem on your telephone line. Make sure that you can get
a dial tone on a telephone handset connected to and through your modem
when the modem (or computer in the case of an internal modem) is turned
Many voicemail systems use a "stutter" dial tone or beeping when you pick
up the phone to indicate that you have voicemail waiting. These unexpected
sounds can make the modem think there is no dial tone. If you must use
the modem on a line with these voicemail or similar sounds, you can try
the following workarounds:
Increase the amount of time that the modem waits for dial tone by setting
the number of seconds to wait in register S6 (e.g., S6=5).
Lower the Xn setting to an odd number value to make the modem
ignore dial tone and dial blindly (e.g., X3 instead of
or even X1).
Your modem may not be designed for the phone system in the country in which
you are trying to use it. As a workaround, try lowering the Xn
setting as described above.
What's wrong with my dialup SLIP/PPP connection?
For more SLIP/PPP help see "Any Trumpet
Winsock tips?" and "Troubleshooting
Make absolutely sure that there is one and only one WINSOCK.DLL
on your system, and that it is the right one.
Make sure that the directory (e.g., C:\TRUMPET) for your
dialup SLIP/PPP package (e.g., Trumpet Winsock, aka TCPMAN)
is in your DOS PATH environment variable.
Try the following settings in your dialup SLIP/PPP package:
For true PPP or SLIP:
TCP MSS: 536
MTU: 576 [MSS + 40]
TCP RWIN: 2144 [MSS x 4]
(For reference see RFC
Note: Increasing RWIN to larger multiples of MSS (e.g., 2680,
3216, 3752, or 4288) may improve performance a bit on sluggish links.
For TIA Pseudo-SLIP (see comments on TIA below):
TCP MSS: 1460
MTU: 1500 [MSS + 40]
TCP RWIN: 4096
(For reference see "Installation
Instructions for Single-User TIA")
Note: There is no significant performance difference between SLIP and
The author recommends the following Winsock applications (all of which
are freeware or shareware):
For more Winsock application information see:
You may be able to run dialup SLIP/PPP from a UNIX shell account with The
Internet Adapter (TIA). Even when your Internet Service Provider offers
a SLIP/PPP option, it may be cheaper to run TIA from a shell account. TIA
is commercial but inexpensive. A freeware alternative is SLiRP. For more
information on TIA and SLiRP see "SLiRP/TIA
and Trumpet Winsock Setup Reference." (Usenet alt.dcom.slip-emulators)
A good tool for debugging SLIP/PPP protocol problems is SerialView
from Klos Technologies.
Why can't I get back on-line after I escape to
While on-line you escape your modem to command mode with "+++", and then
try to get back into data mode with ATO, but the remote system
no longer responds. You have to break the connection to recover.
What's probably happening is that your "+++" escape code is being echoed
by the remote system back to the remote modem, throwing it into command
mode as well, a state from which you cannot recover short of disconnecting.
It really shouldn't be happening, because any BBS SYSOP or Internet Provider
worthy of the name should either disable the escape sequence or at least
change it to an unusual value. But all too many don't.
The solution is to use modem register S2 to change your modem
escape character. The author uses S2=61 to change the escape character
to "=", which is on the same key as "+", making it easy to remember.
Why do I sometimes have problems connecting?
See below and also "Any other USR tips?".
Why do I sometimes get abruptly disconnected?
With a USR 28800 modem, you can determine the technical reason for a disconnect
by issuing the ATI6 command immediately after the disconnection.
Disconnect reasons are explained in the
If you have Call Waiting, the incoming call "beep" may sometimes (but not
always) disconnect you. To avoid this problem, you may be able to temporarily
disable Call Waiting when you make a data or fax call. (See "How
do I shut off Call Waiting?")
If your modem fails to negotiate error correction (V.42/LAPM or MNP4),
the uncorrected transmission errors may make the remote site hang up on
you. To avoid this possibility it's a good idea to force error-correcting
connections; that way if the negotiation of error correction fails, the
modem will fail to connect, and you may be able to configure your software
to retry the connection automatically. In Windows 95/98 you can go to Properties
| Connection | Advanced and check the Required to Connect option; otherwise,
check your modem documentation for the correct option to set in your modem
Disconnections may be caused by momentary drops of DTR by certain comm
applications. (By default most modems respond to a drop of DTR by hanging
With most modems you can work around this problem by disabling DTR (i.e.,&D0).
Note that when DTR is disabled you have to escape the modem to command
mode and use the "ATH" command to hang up.
With USR modems you can also use register S25 to work around the
problem (e.g., S25=10 will ignore a DTR drop of less than
10/100 or 1/10 second, which is twice the default of 5/100 second).
For those experiencing disconnects (and/or erratic connection speeds) when
calling Rockwell-based V.FC modems from a USR 28800 (V.FC or V.34) modem,
a firmware fix is now available for the Sportster (dated 4/18/95 or later
for USA modems) by calling USR (847/982-5151); for the Courier, the fix
(dated 7/5/95 or later for USA modems) is available by FTP.
In the meantime, the author's workarounds (which may help in some cases
even if you have the updated firmware) are:
Disable V.42 Detect Phase (i.e., S27=48).
-- or --
Disable V.42 completely (i.e., S27=32). If you then sometimes
get non-error-correcting connections, force error-correction mode (i.e.,&M5).
You may find that you have to redial several times to get connected; if
so, try the following.
-- and/or ---
Disable the highest symbol rates (e.g., S54.5=1S54.4=1S54.3=1).
This will limit your top speed (to 24000 in this example), depending on
how many symbol rates you disable (3429, 3200, and 3000 in this example).
-- also --
With V.FC-only firmware (as opposed to the newer V.34 firmware) it may
help to also disable the 32S-2D map (i.e., S55.2=1).
-- finally --
It may also help to set S10=255.
If possible, set these options on a phone number-specific basis. With
comm apps which lack that capability, you may be able to embed them in
the phone number; e.g., "^H^HS27=48DT555-1212". (The two
"^H" backspace characters erase the "DT" in an "ATDT"
dial command so that the "S27=48" will be accepted, and then the
following "DT" replaces the "DT" that was erased; i.e.,
"ATDT" + "^H^HS27=48DT555-1212" = "ATS27=48DT555-1212".)
Why do connections sometimes seem to run slower
The following is a discussion of the so-called "spiraling death" problem
that has been observed on the Sportster 28800 (and sometimes even the Courier
V.34), where the modem will fall back over time on certain connections
to ever lower speeds.
What we are really concerned with here is fall-forward, not retraining.
(See "What is 'retraining'? and What are
'fall-back' and 'fall-forward'?") Retraining is normally a rare event.
So the problem is really that the Sportster 28800 sometimes does not fall-forward
it is able to do so. The symptom is that the Sportster 28800 is sometimes
observed to fall back to progressively lower speeds without ever being
observed to fall forward back to higher speeds. The implication is that
line conditions would have permitted a higher speed, which may or may not
have been true. (It's impossible to say for sure without elaborate test
THE ATO1 CONNECT RESPONSE CONFUSION
Some of the evidence used to support the claim that the Sportster 28800
doesn't fall forward has been that ATO1 (forced retraining) returned
the modem to a higher speed. The problem with at least some of these reports
is that people have assumed that the CONNECT response to ATO1
reports the new speed after retraining. It doesn't, as should be obvious
if you notice that the response appears before the retraining sound
(heard with M2) is completed. The response sometimes shows the previous
connection speed, and sometimes shows the original connection speed, but
never the new speed. The only way to correctly determine the connect
speed after retraining is to escape to command mode and use the ATI6
command! (See "Any other USRobotics tips?",
"Any Trumpet Winsock tips?", "Why
can't I get back on-line after I escape to command mode?", and "Any
Windows 95/98 tips?")
Suppose that a phone connection is such that the Sportster 28800 CONNECTs
at a high speed (e.g., 28800), but then falls back to a lower speed
(e.g., 24000) due to line conditions. Escape to command-mode followed
by ATO1 might well make you think that retraining has returned
the modem to the original high speed (due to a CONNECT 28800 response)
when it may well
not have. Disconnecting and reconnecting
could produce the same misleading indications. In other words, these may
just be plain old poor connections. The moral here is that you must use
and only ATI6, to check the current connection speed.
Another problem is that ATO1 may not change the current speed,
or may even reduce it, depending on changing line conditions. And it's
hard to keep ongoing auto fall-back/forward from confusing the issue (unless
you use M2 and listen carefully for the sound of the speed shifts, a small
beep or blip in the ongoing carrier hiss). The only way to know
for sure whether or not the speed changed is to use ATI6 immediately
before and after
Does the Sportster 28800 fall-forward automatically or not? From extensive
testing (literally hundreds of hours to both USR and non-USR modems) the
author concludes that the answer is: often yes, but sometimes no. The author
has run many tests where the Sportster 28800 was forced back to (say) 16800,
and then it rapidly fall forward to a much higher speed. But the author
has also run some tests where it stayed at 16800. This seems to be a function
of both line conditions and the modem at the other end of the connection.
Note that this problem is not absolute -- while some users do encounter
it on some connections, many users never encounter it.
Another possibly related problem that some have reported with the external
Sportster 28800 (not the internal Sportster, and not either type of the
Courier) is that adjusting the speaker volume control while on-line causes
the modem to fall back. Anecdotal reports suggest that higher connection
speeds may be possible if the volume control is turned all the way down
before the initial negotiation (and left there). Turning off the speaker
with M0 is apparently not effective.
WHAT TO DO
USR now has a fix for this problem in the form of updated modem firmware.
Supervisory Update Information". (Note: the dates in the firmware
table are not necessarily the dates of the latest versions.)
While waiting for the fix, here are some workarounds to try:
If possible try a different modem to see if the problems persist or not.
Try to improve your connection -- the Sportster 28800 may be falling back
in response to noise bursts on the line. (See "Why
don't I get 28800 bps speed on my connections?")
If you have the external Sportster 28800, try turning the volume control
all the way down before the initial negotiation.
You can disable fallback on the transmit side (the receive side is not
affected) by setting the undocumented option of S15=2. The downside
is that you may get disconnected if line conditions deteriorate enough
to warrant a fall-back and/or you may experience more retraining. (This
option is documented for the Courier V.34.)
If you have 11/30/94 or later Sportster firmware (date for USA modems),
you can lock the transmit speed (but not the receive speed) in a range
with &Nn&Un (e.g., &N14&U12 locks
the transmit speed between 28800 and 24000). With an appropriate range,
this may be more reliable than S15=2. (However, it does not work
on the Courier.)
Why do my on-line connections "pause"?
You are on-line to a remote system, perhaps a distant system over the Internet
or a local bulletin board system (BBS), transferring data or typing in
commands, when suddenly communications stops. Then after a few seconds,
a few minutes, or possibly even longer, things start flowing again. The
question is, what happened? The answer is, it depends. There are a great
many things that can cause this kind of pausing, and determining the real
cause can often be difficult, sometimes very difficult. Worse, the cause
may be out of your direct control. Here is a list of possible causes, tips
on how to identify them, and suggestions for ways to deal with them:
Telephone connection problems
Modem error recovery
When a transmission error occurs, error correcting modems will automatically
retransmit the affected data. Under normal conditions the retransmission
will be brief, but when connections are poor the retransmissions can result
in "pauses" that last for many seconds. Certain modems will help you diagnose
and/or detect this kind of problem (e.g., with a "link diagnostics"
screen, or flashing ARQ or SQ lights). The only way to completely solve
this problem is to get better connections (see "Why
don't I get 28800 bps (or more) on my connections?"), but it may help
to reduce the connection speed (so as to reduce the frequency of errors).
While modems are retraining due to a poor connection, no data can flow.
Although a single retrain lasts only a few seconds, multiple retrains (and
other related error recovery) can go on for much longer, up to 30 seconds
or more in the author's experience. See "What
Network (Internet) problems
Lost TCP/IP packets
When a TCP/IP network (e.g., the Internet) gets overloaded, the
network routers deal with the problem by dropping (discarding) data packets.
It then takes time for the sender to notice that the receiver hasn't acknowledged
packets that have been sent, and to resend those packets (which may in
turn get dropped). The result is a general slowdown in data transmission
speed, often with long gaps or "pauses." In extreme cases packet loss can
go as high as 30% or more, bringing transmission down to a fitful crawl
with nothing flowing most of the time. This problem can be diagnosed with
"ping" and "traceroute" tools (the use of which is beyond the scope of
this document). The only way to deal with this problem is by complaining
to the network administrator, but there may not be much that can be done
if the congestion problem is outside of the local network (e.g.,
elsewhere on the Internet)
Remote server overload
Remote servers can only handle so much load. When the load gets excessive,
there is a general slowdown to all those using the server, often with long
pauses when the server is busy serving other users. As the Internet grows,
this is becoming an ever-increasing problem, particularly for popular sites.
The only way to deal with this problem is to access the server when the
load is less (e.g., in the wee hours of the morning).
Routing and other problems
Certain networks are adopting packet routing policies, particularly during
periods of peak load, that discriminate against certain users, particularly
smaller ISPs (Internet Service Providers). At best the network may drop
many packets or route them onto slower, more congested links; at worst,
the network may refuse to pass them altogether. The only way to deal with
this problem is to be sure that your ISP has good connectivity (e.g.,
multiple "peering" points, multiple "backbone" connections and/or alternate
transport providers). In the long run the smaller ISPs may simply be squeezed
Flaky serial port (UART)
A flaky serial port (UART) can cause all sorts of communications problems,
including both long and short ("pausing") lockups. See "Why
does Windows lock up when I access my modem?"
Improper flow control
If flow control is not configured properly in both the comm software
and the modem, the result is overruns. These overruns result in lost data,
which can cause "pauses" as well as delays due to data retransmission.
See "Why am I getting CRC errors (overruns)?"
Hardware conflicts are a frequent cause of both long and short ("pausing")
lockups, particularly when two COM ports are set to the same I/O address
or IRQ. For example, a mouse on COM1 and a modem on COM3 will normally
product such a conflict. (Sometimes moving the mouse will cause modem data
to flow, but in other cases the modem may work fitfully or not at all.)
See "Why am I getting CRC errors (overruns)?"
Improper TCP/IP configuration can lead to packet fragmentation and other
problems that may be manifested as "pausing." See "What's
wrong with my dialup SLIP/PPP connection?"
Software configuration and interference
Configuration problems in comm software applications can also result in
"pausing." The only solution is to ensure that all comm applications are
configured properly. It is also possible for two software applications
and/or device drivers (particularly network drivers) to interfere with
each other enough to cause a "pausing" problem; the only solution is to
eliminate (one of) the offending application(s).
Operating system swapping
Sometime the operating system suddenly needs a lot more memory for a given
application, and has to swap megabytes of data between memory and a disk
drive. On less sophisticated operating systems (e.g., Windows),
this can result in a "pause" in communications during the swapping. The
symptom of this problem is a large burst of disk activity.
Modem firmware problems
The simplest and most effective way to deal with a modem problem is
to return the modem to the dealer from whom you bought it for refund, credit,
or exchange. (Even when you are outside of the normal return period,
many dealers will still take back the modem for credit or exchange, particularly
if you are persistent.)
Certain USRobotics Sportster modems with firmware dated in February and
March of 1996 have a firmware timing problem that can cause the modem to
"pause" when the modem is being used in an interactive mode on a normal
dialup connection, typically when typing commands while connected to a
Bulletin Board System (BBS) or asynchronous dialup UNIX shell. The "pause"
will clear itself if you wait long enough (up to about a minute). To troubleshoot
and correct this problem, see "Sportster
Supervisory Update Information". (Note: the dates in the USR
firmware table are not necessarily the dates of the latest versions.) For
more SRO information see "USRobotics on the
Note: USRobotics recommends initializing the modem with S12=0
(which disables the modem escape code) as a work-around for this problem.
author recommends S12=0S2=255, which is more robust.
The author recommends that anyone with an affected modem exchange,
update, or return it.
Incompatibilities between certain modems can result in a variety of problems,
including "pausing." If disabling V.42 (and falling back to MNP) causes
the problem(s) to go away, then you probably have an interoperability problem.
A firmware upgrade that corrects the problem may be available for your
modem. See "Which modem companies have a full
Why does my Windows 95 Internet run
The MaxMTU Fix
Note: This problem is finally fixed in Windows 95 Dial-Up
Networking 1.4 Upgrade (as well as in Windows 98). This author strongly
recommends upgrading rather than following the procedure below.
Have you found that your Internet file transfers (e.g., downloads)
are very slow, in the range of 1,000-1,600 characters per second, even
on a 28800 modem connection? It may just be Internet overload; on the other
hand it may be a symptom of a Windows 95 MTU (Maximum Transmission Unit)
problem. To find out which it is, compare the display of "Bytes received/sec."
Monitor (see "Any Windows 95/98 tips?"
to set that up) to the characters per second reported by your downloading
application (e.g., FTP client or Web browser). These two values
should be within about 10%;
e.g., if your "Bytes received/sec."
is 3,300 (typical of compressed data on a good 28800 connection), your
characters per second should be about 3,000. If instead the characters
per second is 1,000-1,600, you are getting a lot of wasted retransmissions
that are probably due to the Windows 95 MTU problem.
The only reliable work-around that this author has found for this problem
is to add the "MaxMTU" parameter to your Registry and set it to a value
of 576. (MaxMTU and other networking parameters are documented in the free
Windows 95 Resource
Kit Help File.) There are two ways to accomplish this:
Note: This author has found no significant benefit from adjusting
other TCP/IP parameters (as certain other sources have suggested); e.g.,
there is no need to fool with "DefaultRcvWindow" (receive window) or "DefaultTTL"
(time to live).
Download and install TCPIPCFG, a Control
Panel "applet" written by this author that makes it easy to adjust MaxMTU.
The latest version of this applet (released 11/11/97) will run on Builds
950 (including 950a, aka "OSR1") and 1111 (aka "OSR2") of
Windows 95, and includes support for multiple DUN connections. (If you
using an earlier version of this applet, install the update, and then be
sure to reset your MaxMTU value.)
This applet will not work on at least some non-English language versions
of Windows 95; e.g., Catalan.).
To uninstall the applet, first use it to set a blank value
for MaxMTU, and then delete TCPIPCFG.CPL from your \WINDOWS\SYSTEM directory.
Follow the manual procedure.
Note: There are (unconfirmed) reports that MaxMTU does not work
properly with SLIP, as opposed to PPP, connections.
The Default Receive Window Fix and Hack
The following was contributed by Eric
"Occasionally one sees slow downloads over dial-up PPP connections.
I have never seen a plausible explanation for this in the comp.os.ms-windows.*
newsgroups, but did find an explanation in one of the UNIX
"Apparently Solaris 2.3/2.4/2.5 have a TCP/IP bug that causes every
packet to be sent twice when the network delay exceeds some threshold.
You will observe the modem receiving data most of the time, but the transfer
rate will be half of what it should be (1.6KB/s for 14.4, 3.2KB/s for 28.8).
"You can work around this bug both on the server and in Windows 95.
If your provider's Sun server has this problem, make them fix it! [See
"TCP network measures" in "Watching
your Web server"]
"In Windows the work-around is to reduce the Default Receive Window
from its default of 8192, thereby reducing the network delay. I haven't
verified this myself, as I rarely see the problem. If you can verify this
solution, let me know and I will get it into an FAQ.
"If you aren't using TCP/IP on a LAN, you can set Receive Window to
4096 with no drop in performance and an improvement in interactive response
(while downloading) of one or two seconds. Reducing the size of the Default
Receive Windows probably is probably a general fix for many "mysterious"
bugs, including the Solaris bug.
"Here is a registry hack that makes changing
TCP/IP parameters easy. Maybe Microsoft could incorporate these changes
[Note: No benefit was observed from the Default Receive Window
Fix in extensive testing by the author of this FAQ, and the Hack appears
to produce results inconsistent with Microsoft documentation on Default
Receive Window. It is therefore presented here only in the hope that it
might help those for whom MaxMTU might not work.]
How do I shut off Call Waiting?
Why won't Call Waiting interrupt my modem connection?
Call Waiting is a phone service option that allows you to be interrupted
by an incoming call while you are using the phone line. If you are using
the phone line for data or fax, the "beep" that signals the incoming call
can cause an abrupt disconnection, which can be a problem.
To temporarily disable Call Waiting for a single outgoing call, there
is often a special code that can be dialed before the phone number. With
tone dialing service, this special code is usually "*70" (e.g.,
instead of dialing say "555-1212", you would dial "*70,555-1212", with
the comma being used to signal your modem to insert a brief pause between
the special code and the phone number); with pulse dialing service, this
special code may be "1170". Check with your local phone company to be
sure. Better comm programs have an option to insert the special code
On the other hand, you may actually want Call Waiting
to interrupt a data or fax call, so that you do not miss an important incoming
call. However, V.34 modems are designed to overcome "line noise" like Call
Waiting, and they may not be disconnected by the "beep." However, there
are specific devices (not tested by this author) that are designed
to make this work:
Add-on Call Waiting Detectors
How do I keep my data/fax call from being interrupted?
It goes like this. You have a single line with multiple extensions that
you use for both voice and fax/data. You are on-line in the middle of a
large file transfer. Someone else picks an extension in another room, and
bang, your connection is lost sending the file transfer down the drain.
There is an easy way to prevent this problem. Obtain a "Line Protector"
for each extension phone. When your modem is on-line, the Line Protector
will automatically prevent the attached phone from interrupting your connection.
A Line Protector is inexpensive, and readily available on the Internet
(e.g., Black Box or Hello
Direct) or from Radio Shack (which calls it a "TeleProtector"). Some
"Call Routers" will also provide this kind of protection. (See "How
can I use a single phone for fax/data/voice?")
How can I make fax work better?
There are three popular standards for fax modem commands (used by fax software
Consumer-grade fax modems have a number of weaknesses and deficiencies,
not all of which can be completely overcome. That noted, here are some
suggestions for making your fax work better:
A low-level standard, Class 1 puts the most burden on your fax software
and your host CPU, but also gives the most control. Slower systems may
have problems sending and receiving faxes in the background with Class
A de facto standard promulgated by Rockwell, so-called Class 2 is widely
supported by fax software, and takes much of the low-level load off of
your system, which can improve faxing in the background, particularly if
you have a slower system.
A true standard for higher-level fax commands, Class 2.0 is notably supported
by USRobotics, but is not widely supported in software as of this writing.
It is not compatible with Class 2, although it can provide similar
High-end fax modem products have significantly better fax machine coverage,
reliability, and performance than consumer-grade fax modems. Such products
are made by:
If you are having trouble getting fax to work at all, try any software
that came bundled with your fax modem. While that software may not be fully
satisfactory, it should at least tell you whether your fax modem is working
properly or not.
Make sure that you have specified the correct fax Class for your
modem in your fax software.
Make sure that you have the latest updates for your fax software.
Make sure that you are using the recommended initialization string for
Slower systems may have problems faxing at 14.4 Kbps. If you are having
problems, try dropping the maximum fax speed down to 9600 bps, if possible.
Slower systems in particular may not be able to do much in the foreground
without interfering with background faxing, particularly with Class 1.
32-bit operating systems like OS/2 Warp, Windows NT, and Windows 95/98
are better able to handle fax in the background than 16-bit operating systems
like Windows 3.x.
For fax reliability on a budget consider a Rockwell-based
fax modem -- Rockwell makes most of the fax chipsets in fax machines, so
Rockwell-based fax modems tend to have an edge in fax interoperability.
See other fax tips throughout this document.
What modem initialization string should
The best resource for modem initialization strings is the documentation
that came with your modem, or other information provided by your modem
Windows 95/98 comes with INFormation files that provide proper initialization
for many popular modems. (It is very important to use the
and latest INF file for your modem -- "Standard modem" may well
cause problems. See "Installing your modem 'driver'" under "Any
Windows 95/98 tips?")
Many comm apps are another good resource, because they come with recommended
modem initialization strings.
An online resource is Ask Mr.
Modem. Note: This author cannot vouch for the accuracy of Ask
There is no "magic" initialization string that will overcome communication
line problems -- your modem will negotiate and maintain the best connection
it can automatically.
Trademarks belong to their respective owners.