From news.csc.fi!news.funet.fi!news.kolumbus.fi!news.sprintlink.net!aimnet.com!news2.aimnet.com!usenet Wed Dec 6 13:12:33 1995
Path: news.csc.fi!news.funet.fi!news.kolumbus.fi!news.sprintlink.net!aimnet.com!news2.aimnet.com!usenet
From: JNavas@NavasGrp.com (John Navas)
Newsgroups: comp.dcom.modems
Subject: The Navas 28800 Modem FAQ -- 2/5
Date: Sat, 25 Nov 1995 21:36:55 GMT
Organization: The Navas Group, Dublin, CA, USA
Lines: 722
Message-ID: <49823m$754@news2.aimnet.com>
References: <483f6b$lkt@news2.aimnet.com>
NNTP-Posting-Host: dial-bp1-8.iway.aimnet.com
X-Newsreader: Forte Free Agent 1.0.82
<<cont>>
Why am I getting CRC errors (overruns)?
CRC errors (e.g., as reported by ZMODEM), 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?[106]" and "Why does Windows lock up when I access my
modem?[107]") (Most, but not all, internal modems use 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.
If you determine that your video driver is causing overruns,
check to see if your video card uses a recent S3 chipset (e.g.,
864, 964, or 968). If so, there may be an option in the video
driver to set "Bus-throttle=On" (usually Off by default), 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 the S3 BBS at 408/654-5676.
Unfortunately, they do not work on all S3-based video cards.)
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. (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.
Disable write caching on your download disk drive. (Read
caching should be OK.)
* 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[108]")
* With 32-bit File Access under Windows for Workgroups, put
the following in the [386Enh] section of your SYSTEM.INI file:
ForceLazyOff=<drives>
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[109]")
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, especially if you are using
a serial mouse. (COM2 has higher interrupt priority than
COM1.)
Under Windows, put the following in the [386Enh] section of
your SYSTEM.INI file:
MinTimeslice=20
WinTimeslice=100,50
COMnFIFO=1
COMnBuffer=1024
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[110]")
Do not use Microsoft's PC speaker sound driver[111]! Get a
cheap sound card instead. (The Logitech Factory outlet in
Fremont, California, 800/231-7717, is a good place to get a
cheap sound card.)
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 communications.
Disable any screen savers, which can interfere with data
communications.
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.
Try a third-party replacement for COMM.DRV. (See What about
third-party comm drivers for Windows?[112])
Switch to Windows for Workgroups or Windows 95, 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?[113]") under regular Windows and a third-party comm
driver (e.g., WFXCOMM.DRV[114]) or Windows for Workgroups or
Windows 95, 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). 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.
Button[115] [Return to top[116]]
___________________________________
What's wrong with my dialup SLIP/PPP connection?
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 879[117])
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[118]")
For more SLIP/PPP help see "Any Trumpet Winsock tips?[119]" and
"Troubleshooting Reference[120]."
Note: There is no significant performance difference between
SLIP and PPP. (See "SLIP vs PPP Performance Comparison[121]" and
"Performance Issues[122]")
The author recommends the following Winsock applications (all of
which are freeware or shareware):
Dialup TCP/IP (SLIP/PPP) stack: Trumpet Winsock (See Any Trumpet
Winsock tips?[123]) (Usenet alt.winsock.trumpet[124]):
Version 2.0B[125] (no enforced limit on evaluation)
Version 2.1F[126] (enforced 30-day limit on evaluation)
WARNING: Earlier 2.1 versions have serious bugs and should
not be used.
WARNING: The author has found problems with streaming ZMODEM
uploads in a telnet session over a Trumpet TCP/IP link. A
work-around is to set a ZMODEM window size of 2 Kb.
Mailer: Pegasus Mail for Windows[127] (Usenet
bit.listserv.pmail[128])
Web browser: Netscape[129]; helper applications:
Acrobat viewer: Adobe Acrobat Reader[130]
QuickTime[131] video player
Real-time audio: Real Audio Player[132]
TIFF viewer: LView Pro[133]
ZIP viewer: WinZip[134]
Usenet newsreader: Free Agent[135]
FTP (File Transfer Protocol): WS_FTP[136]
Telnet (login to remote host): EWAN[137]
Ping (is host alive): WS_PING[138]
Finger (find user) and WhoIs (find host): WSFINGER[139]
NSLookup (lookup DNS names): NSLookup[140]
Set clock from network timeserver: Tardis[141]
HTML editor: Microsoft Internet Assistant[142] (Word for
Windows 6.0a or above required)
Graphic Editor: Paint Shop Pro[143]
Tranparent GIF converter: LView Pro[144]
Sound Editor: Cool Edit[145]
For more Winsock application information see:
"Stroud's Consummate Winsock Apps List[146]"
(files available at The Papa Winsock-L FTP Site[147])
"The Ultimate Collection of Winsock Software[148]"
Usenet alt.winsock[149]
You may be able to run dialup SLIP/PPP from a UNIX shell account
with The Internet Adapter[150] (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[151]."
(Usenet alt.dcom.slip-emulators[152])
Button[153] [Return to top[154]]
___________________________________
Any Trumpet Winsock tips?
Where to get Trumpet Winsock:
Version 2.0B[155] (no enforced limit on evaluation)
Version 2.1F[156] (enforced 30-day limit on evaluation)
WARNING: Earlier 2.1 versions have serious bugs and should
not be used.
WARNING: The author has found problems with streaming ZMODEM
uploads in a telnet session over a Trumpet TCP/IP link. A
work-around is to set a ZMODEM window size of 2 Kb.
You can monitor Trumpet Winsock TCP/IP performance with
TCPMeter. (Execute once Trumpet Winsock is running. Click the
left and right mouse buttons to expand and contract the graph
scale respectively, and try a scale of 4K or 8K for a 28.8
connection. Incoming speed graph bars point down; outgoing
point up. Note that TCP/IP is a full duplex link where data can
flow at full speed in both directions at the same time.)
Here[157] for Trumpet Winsock 2.0
Included with Trumpet Winsock 2.1 (do not use the 2.0
version)
Trumpet Winsock 2.0B locks an excessive amount of memory (107
Kb) below 1 Mb; 2.1F is improved, but still takes a substantial
amount (44 Kb) of low memory. (See "Any other Windows
tips?[158]") The amount of low memory is not affected by the
TCP/IP settings.
The following Trumpet Winsock script fragment will auto-redial
(e.g., on BUSY), assuming that $number has been initialized
with the number you want to dial:
repeat
sleep 2 # gives modem time to recover after connect failure
outputecho "atdt"$number\r #dial number
repeat
read 90 $result # read modem response
# wait for long response, ignoring normal intermediate response
s
until len($result) >= 4 & pos("~" + copy($result, 1, 4), "~RING
ING~CARRIER~PROTOCOL") = 0
until pos("CONNECT", $result) = 1 # retry if I did not connect
The author recommends configuring your modem for Trumpet
Winsock with &D1 rather than &D2; that way you can use DTR
rather than the escape code to enter modem commands when
online.
The following Trumpet Winsock ATI6.CMD script can be used with
a USR modem initialized with &D1 to display Link Diagnostics
(e.g., the current modem-to-modem speed) when online:
set dtr off # put modem in command mode (&D1)
if [input 2 OK\n] # wait for modem response
end
set dtr on
output at\r # make sure modem is alive
if ! [input 1 OK\n]
display \n"*** Modem is not responding!"\n
abort
end
display \n"*** USR Link Diagnostics follow:"\n\n
echo on
output ati6\r
if [input 5 OK\n]
display \n"*** End of USR Link Diagnostics."\n\n
end
output ato\r # change to ATO1 to force a retrain
input 15 CONNECT
input 1 \n
online # can probably get back online with SLIP, but not PPP
The following Trumpet Winsock BYE.CMD script can be used to
quickly disconnect your modem (configured with either &D1 or
&D2):
set dtr off # modem command mode (&D1) or disconnect (&D2)
if [input 2 OK\n] # wait for modem response
end
set dtr on
output athz\r # hangup command (&D1 or just to be sure with &D2)
input 2 OK\n
display "Disconnected."
sleep 1
Button[159] [Return to top[160]]
___________________________________
Why 1024 bytes for the Windows COM buffer?
The buffer size is mostly a flow control issue. When the buffer
fills up above the "high water mark" (e.g., 75%), a Windows comm
driver asserts receive flow control; then when it drops below the
"low water mark" (e.g., 25%) a Windows comm driver releases
receive flow control. (A Windows comm application should have
nothing to do with flow control. DOS applications, on the other
hand, do not use the Windows comm driver and so must do their own
flow control.)
For Windows applications then the only serious issue is that the
size of the buffer between the "high water mark" and buffer-full
must be big enough to give the local modem time to respond to flow
control being asserted -- there is inevitably a certain amount of
"dribble," but it's usually no more than about 10-20 characters,
for which even the default 128-byte buffer should be adequate. For
performance you want the buffer large enough for the Windows
application to be able to process incoming data in reasonable
sized chunks. (You also want the modem to respond to flow control
being released before the buffer is drained by the application,
although this is much less important due to modem buffering.) Thus
if multitasking is going on, a somewhat larger buffer than the
default (e.g., 256-1024) may improve performance. The higher end
of the range accommodates a typical (YMODEM/ZMODEM) block. Beyond
that point diminishing returns set in rapidly.
For DOS applications the buffer size is more important, since
the DOS application is responsible for flow control and takes much
longer to respond than a Windows comm driver. That's why it's a
good idea to have a receive buffer as big as a typical
(YMODEM/ZMODEM) block (i.e., 1024 bytes). The alternative is to
turn the buffer off completely and give the DOS application direct
access to the COM port by setting a buffer size of 0.
On the transmit side (where there's no flow control concern) the
only consideration is performance -- you want the buffer to be big
enough so that it doesn't drain to empty when the application is
unable to respond fast enough to refill it. The default 128-byte
buffer will drain in only 22 ms at 5760 cps, which is less than a
single multitasking timeslice. A 1024-byte buffer takes 178 ms to
drain, which is normally sufficient; above that point diminishing
returns set in rapidly. One reason is that modem buffering can
make up for (short) times that the transmit buffer drains to
empty. And if you make the transmit buffer too large, it can
introduce timing problems (due to the "long" buffer drain time)
with DOS applications and with poorly written Windows
applications.
Button[161] [Return to top[162]]
___________________________________
What is "retraining"?
What are "fall-back" and "fall-forward"?
It's very important to properly distinguish between (a)
retraining and (b) fall-back/forward. They are frequently confused
but they are not the same thing. If you turn on the modem speaker
with M2 you can easily hear the difference.
RETRAINING
Retraining is like the initial training -- several seconds where
the modems probe the line in order to configure themselves
(equalization, nonlinear coding, pre-emphasis, pre-coding,
shaping, mapping, etc.). Either modem can request a retrain, but
the retrain will only occur if the other modem grants it. You can
hear the distinctive training sounds if the modem speaker is on.
During the several seconds of retraining no data can flow. Because
of that we want the modems to only retrain when truly necessary,
as when line conditions have changed significantly and
permanently, something that is usually rare. Retraining may not
necessarily result in a higher speed. Excessive retrains can
therefore be a serious problem.
FALL-BACK/FORWARD
Fall-back/forward is simple speed shifting that is relatively
quick, so we would like the modems to fall back when needed to
keep the error rate low, and fall forward when possible to improve
throughput. With the modem speaker on you will hear only a small
beep or blip in the carrier hiss. If a noise burst causes a
fall-back, we want the modems to fall-forward as soon as the burst
is gone. What we don't want is for the modems to ping-pong back
and forth between two speeds, because that would result in lower
throughput than simply remaining at the lower speed. Again,
fall-back/forward can be requested by either modem, but will only
occur if the other modem permits it.
Button[163] [Return to top[164]]
___________________________________
How do I set a speed greater than 19200 bps in Windows?
You can set a speed faster than 19200 in the Windows Control
Panel by simply typing it in. However, there is almost never a
need to do so -- almost all Windows comm applications set their
own serial port speed. The settings in the Control Panel are
primarily for devices attached to the serial port; e.g., printers.
(See "Control Panel Serial Port Settings Are for Printing
Only[165]")
Button[166] [Return to top[167]]
___________________________________
What about third-party comm drivers for Windows?
Despite "urban legends" to the contrary, the standard Windows
3.1 COMM.DRV is capable of supporting high-speed modems on a
reasonably fast system, and does support the 16550 FIFO. (See
"Windows Support of the 16550 UART[168]") However, it does have
three limitations:
It does not use the transmit FIFO. This rarely makes any
difference for data, but can be a problem for Class 1 fax
timing above 9,600 bps.
The receive FIFO threshold is fixed at 14 bytes, which leaves
only 2 bytes before overrun occurs. Dropping the receive
threshold to 8 bytes (or even lower) may help to reduce
overruns. For that you need a third-party comm driver.
DOS comm programs running under Windows 386 Enhanced Mode are
fooled into thinking that the COM port only has a 16450 UART.
This can cause problems, particularly with poorly-written DOS
comm programs (i.e., those that do not drain the UART buffer on
each receive interrupt). The alternative is to give the DOS
application direct access to the COM port (see "Why 1024 bytes
for the Windows COM buffer?[169]") or, better yet, upgrade to
Windows for Workgroups 3.11 or Windows 95.
Also despite "urban legends" to the contrary, COMM.DRV supports
speeds up to 256,000 bps, hardware permitting, including 115,200
bps. (See "Setting Baud Rates in Windows 3.1[170]") How fast you
can go will depend on your hardware. With only an 8250 or 16450
UART, you may not be able to go faster than 19,200 bps without
overrun; with a 16550 UART and a reasonably fast system, you
should be able to go up to 57,600 bps, or even 115,200 bps. 57,600
bps is normally adequate for even a 28,800 bps 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.
Third-party comm drivers include the freeware:
CYBERCOM.DRV[171]
WFXCOMM.DRV[172] (from Delrina[173], particularly reco
mmended for use with WinFax)
Third-party drivers are not needed for and should not be used
with Windows for Workgroups 3.11 or Windows 95, which have a
better comm architecture than standard Windows. An upgrade to
Windows for Workgroups 3.11 or Windows 95 is probably the best way
to improve Windows communications. (See "Any other Windows
tips?[174]") Third-party Windows drivers should also not be used
with OS/2 (Warp).
Button[175] [Return to top[176]]
___________________________________
How can I share a modem between data and WinFax?
Delrina WinComm PRO can seamlessly share a modem with Delrina
WinFax PRO. With WinFax PRO set to automatically answer the
telephone, WinComm PRO will turn off WinFax PRO auto-answer to
dial out, and turn WinFax PRO auto-answer back on when it is
through with the modem. The two programs may be purchased
together in a discounted bundle called the Delrina Comm Suite.
With other data comm programs you can use WfListen[177], a
program that will shut down Delrina WinFax when you start your
data comm program, and then restart WinFax when you shut down
your data comm program, all automatically. Shareware. (A
companion program, wfStatus[178], modifies the WinFax icon to
show whether it's ready to receive faxes or not. Also
shareware.)
Another alternative is KingComm, a commercial virtual comm port
driver that allows multiple comm apps to share the same modem.
Multi-Tech[179] provides a proprietary "Virtual Modem" comm
driver for Windows with certain modems that will reportedly
route incoming data and fax calls to appropriate applications.
However, it does not support the 16550 FIFO buffers, a serious
drawback. (See "Do I need a 16550 UART? What is a UART?[180]")
Note: Except for Multi-Tech, these alternatives do not have the
ability to automatically detect and properly route incoming data
and fax calls. For that you need a modem that supports "Adaptive
Answer" (called "Call Select" by USRobotics), as well as data and
fax comm software which support that capability (e.g., Procomm
Plus for Windows 2.xx[181]).
Button[182] [Return to top[183]]
___________________________________
How can I display the status of an internal modem under Windows?
ModemSta[184] displays an animated icon replica or larger
indicator displays of modem's front panel. Several 3D looks, with
customizable colors. For use with internal, external and PCMCIA
modems. Modem initialization, logging of incoming calls and
connections, additional status info, show communications settings,
generation of sounds at comm events. Can also monitor parallel
ports. Shareware US$15.
Note: It is not possible to continuously display the
modem-to-modem speed of an internal modem. (Some drivers and
applications display data throughput, but that is not the same
thing.) The reason is that you have to have to escape the modem to
command mode and issue a special command, if available, which
interrupts the flow of data. (See "Any other USRobotics
tips?[185]")
Button[186] [Return to top[187]]
___________________________________
Why does Windows lock up when I access my modem?
The most common cause of this problem is a 16550-compatible chip
that isn't fully compatible. Typically this is seen on Pentium
systems with serial ports integrated on the motherboard, but it
can also happen with add-on cards, particularly "multi-I/O" cards
based on popular SMC[188] chips. (See "PC Hangs While Running a
Communications Application[189]" and "16550 UART FIFO Support
under Windows NT[190]")
Updated drivers are available from SMC and Microsoft to work
around the problem. The SMC package[191] includes both SMC's
updated COMM.DRV for regular Windows 3.1 and Microsoft's
updated SERIAL.386 for Windows for Workgroups 3.11; the
Microsoft package[192] includes only Microsoft's updated
SERIAL.386 (10,620 bytes dated 2/17/94). But see warning
below.
Alternatively you should be able to completely solve (or simply
test) the problem by turning off the UART FIFO buffers. To do
that under regular Windows 3.1 or Windows for Workgroups 3.11,
put the following in the [386Enh] section of your SYSTEM.INI
file:
COMnFIFO=0
where n is the number of your modem COM port (e.g.,
COM2FIFO=0). Under Windows NT see "16550 UART FIFO Support under
Windows NT[193]." The drawback is that you then won't get the
benefit of the 16550 FIFO buffers. (See "Do I need a 16550
UART? What is a UART?[194]")
Warning: Although Microsoft specifically identifies the SMC '665
chip as the problem, the author has personally verified that a
problem also exists in the SMC '666 chip (FDC37C666GT).
Furthermore, although the original FIFO problem is reportedly
fixed in current chip production, the author has personally
verified that a problem (perhaps a different problem) still exists
as of August 1995. The author has also personally verified that:
SMC's updated COMM.DRV does not correct this current problem;
and
Microsoft's updated SERIAL.386 is not fully satisfactory:
lockups are very rare but not entirely eliminated, and Windows
multitasking is adversely affected during certain
communications operations (e.g., negotiating a dialup PPP link
with Trumpet Winsock 2.1F[195]).
The only fully effective workaround is to disable the FIFO
buffers (as described above). For this reason the author does not
currently recommend products that use SMC "multi-I/O" chips.
Button[196] [Return to top[197]]
___________________________________
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.
Button[198] [Return to top[199]]
___________________________________
<<cont>>
