IWAY 500 Winner

Selected by PC Webopaedia Selected by
PC Webopaedia

Navas 28800-56K Modem FAQTM 

(Answers to Frequently Asked Questions)

[Modem Picture]

Cable modem/DSL users: see Navas Cable Modem/DSL Tuning GuideTM


Copyright 1999-2017 The Navas 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>.

Important Notes:

Breaking News


Main Contents
Navas Group Home Page

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, not 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 your documentation.)

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, the 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 near-perfect connection.)

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.

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.
This Section
Main Contents
Navas Group Home Page

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):
  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.
  2. 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.
  3. 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?")
  4. If you determine that your video driver is causing overruns:
    1. 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.)
    2. 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.
    3. 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.
  5. 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.
  6. 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.
  7. 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?")
  8. Disable write caching on your download disk drive. (Read caching should be OK.)

  9. * 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. (See "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 "How to Disable Write Caching for the 32-Bit File System")
  10. 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.)
  11. Beware of TSRs, especially network TSRs. Try booting your system as clean as possible to see if that helps.
  12. Watch out for certain memory managers; e.g., the use of QEMM "Stealth" may cause problems.
  13. 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?")
  14. Under Windows, put the following in the [386Enh] section of your SYSTEM.INI file:

  15. MinTimeslice=20
    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")
  16. Do not use Microsoft's PC speaker sound driver! Get a cheap sound card instead.
  17. 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 version.
  18. Watch out for an IRQ conflict. (You normally cannot use both COM1 and COM3, or COM2 and COM4, at the same time.)
  19. On a portable or "green" machine, you should also try disabling the power management features, which can sometimes "kick in" and interfere with data communications.
  20. Disable any screen savers, which can interfere with data communications.
  21. Don't run your serial port any faster than necessary. Marketing hype notwithstanding, there's 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")
  22. Try a third-party replacement for COMM.DRV. (See What about third-party comm drivers for Windows?)
  23. Switch to Windows for Workgroups or Windows 95/98, which have a better serial architecture than standard Windows 3.x.
  24. 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:

  25. * WFXCOMM.DRV (default 14): ComnRXSize=8 (e.g., Com1RXSize=8). Recommended setting.
    * 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.
This Section
Main Contents
Navas Group Home Page

Why is my modem getting NO DIAL TONE?

  1. 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.
  2. 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.
  3. 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.
  4. 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 off.
  5. 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:
    1. 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).
    2. Lower the Xn setting to an odd number value to make the modem ignore dial tone and dial blindly (e.g., X3 instead of X4, or even X1).
  6. 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.
This Section
Main Contents
Navas Group Home Page

What's wrong with my dialup SLIP/PPP connection?

  1. Make absolutely sure that there is one and only one WINSOCK.DLL on your system, and that it is the right one.
  2. 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.
  3. Try the following settings in your dialup SLIP/PPP package:
For more SLIP/PPP help see "Any Trumpet Winsock tips?" and "Troubleshooting Reference."

Note: There is no significant performance difference between SLIP and PPP.

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)

Advanced/Professional Users

A good tool for debugging SLIP/PPP protocol problems is SerialView from Klos Technologies.
This Section
Main Contents
Navas Group Home Page

Why can't I get back on-line after I escape to command mode?

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.
This Section
Main Contents
Navas Group Home Page

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 Courier manual.

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".)
This Section
Main Contents
Navas Group Home Page

Why do connections sometimes seem to run slower and 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 when 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 equipment.)


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


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.


USR now has a fix for this problem in the form of updated modem firmware. See "Sportster 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:

This Section
Main Contents
Navas Group Home Page

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).
Modem retraining
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 is 'retraining'?"

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

Computer problems

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 conflict
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)?"

Software problems

TCP/IP configuration
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

USRobotics Sportster
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 Internet".

Note: USRobotics recommends initializing the modem with S12=0 (which disables the modem escape code) as a work-around for this problem. This author recommends S12=0S2=255, which is more robust.
The author recommends that anyone with an affected modem exchange, update, or return it.
Modem interoperability
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 Internet presence?"
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.)
This Section
Main Contents
Navas Group Home Page

Why does my Windows 95 Internet run at half-speed?

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." in System 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:

  1. Download and install TCPIPCFG, a Control Panel "applet" written by this author that makes it easy to adjust MaxMTU.

  2. Important notes:
    1. 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.)
    2. This applet will not work on at least some non-English language versions of Windows 95; e.g., Catalan.).
    3. To uninstall the applet, first use it to set a blank value for MaxMTU, and then delete TCPIPCFG.CPL from your \WINDOWS\SYSTEM directory.
  3. Follow the manual procedure.
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).

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

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

"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 into nettrans.inf.

[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.]
This Section
Main Contents
Navas Group Home Page

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

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:

This Section
Main Contents
Navas Group Home Page

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?")
This Section
Main Contents
Navas Group Home Page

How can I make fax work better?

There are three popular standards for fax modem commands (used by fax software applications):
Class 1
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 1.
Class 2
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.
Class 2.0
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 benefits.
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: High-end fax modem products have significantly better fax machine coverage, reliability, and performance than consumer-grade fax modems. Such products are made by:
This Section
Main Contents
Navas Group Home Page

What modem initialization string should I use?

  1. The best resource for modem initialization strings is the documentation that came with your modem, or other information provided by your modem manufacturer.
  2. Windows 95/98 comes with INFormation files that provide proper initialization for many popular modems. (It is very important to use the correct and latest INF file for your modem -- "Standard modem" may well cause problems. See "Installing your modem 'driver'" under "Any Windows 95/98 tips?")
  3. Many comm apps are another good resource, because they come with recommended modem initialization strings.
  4. An online resource is Ask Mr. Modem. Note: This author cannot vouch for the accuracy of Ask Mr. Modem.
  5. There is no "magic" initialization string that will overcome communication line problems -- your modem will negotiate and maintain the best connection it can automatically.
This Section
Main Contents
Navas Group Home Page

Trademarks belong to their respective owners.