                    Maximizing USR Courier Performance
                    ==================================

                               By Alex Boge
                               ============


     The contents of this file are Copyright 1991-1992 by Alex Boge.  All
rights reserved.  You may distribute this freely, without charge, so long
as no portion of this document is modified.  While nothing I describe or
suggest in this document should be harmful to any part of your computer
system or modem, I will not be responsible for anything (my parents told me
that a long time ago).


     US Robotics Courier Modems and Max Speed
     ========================================

     Congratulations!  You have a US Robotics Courier modem.  You own what
I consider to be the best modem available today and the best value too.  An
impossible combination to resist.  This document deals with newer genera-
tions of the Courier modem.  Your modem should be capable of using the
v.42bis protocol.  Check your manual (or try entering AT&K3, if it works,
you've got v.42bis).

     This text file will tell you, in no uncertain terms, how to get THE
maximum performance out of your modem.  I'll lay it out in simple, layman
terms.  I'll give you the easy setup information first.  If you don't want
to learn more, that's up to you.  If you really want to know the nuts and
bolts of it all, just read further.  It's up to you.  We live in America,
land of freedom and unlike our school systems, here in computer land you
still can decide when enough is enough and leave the details in the hands
of professionals like myself.  Instant proof.  Here is the quickest way to
get the best performance out of your HST in three easy steps:

Step 1) Set your DIP switches.  These are the default settings:
1-UP 2-UP 3-DOWN 4-UP 5-DOWN 6-UP 7-UP 8-DOWN 9-UP 10-UP

     Setting DIP switch 9 DOWN will allow you to examine performance
     while still connected and I recommend changing it.  This will NOT
     affect performance in any way.  Older Courier modems may have
     different default settings, check your settings.

     Steps 2 & 3 should be entered from your communications program.  Set
the COM port speed to 38400 bps (or 19200 if that's as fast as you can go). 
Your communications program must use hardware (or CTS/RTS) flow control.

Step 2) AT&F                       This restores factory default settings
Step 3) ATX4&B1&C1&D2&H1&K3&R2&S1&W     This sets & stores max performance.

     That's it folks.  You will now have the fastest (about 100 Kb per
minute) possible download or upload speed you can get out of your Courier
modem.  I know it seems simple but that's the beauty of a well designed
product.  There are some other things to consider though, like which
transfer protocol you should use (Ymodem-g versus Zmodem-90 (MobyTurbo)
versus HS/Link versus the rest), which link protocol to use when both are
available (v.32 versus HST) and whether or not to use compression and which
one (MNP 5 versus v.42bis).

     Since we covered the setting up of your modem so briefly, I will do
the same for these other considerations.  If you want details, read further
in this document.  If you want solid answers, look below.


v.32 versus HST Link Protocol
=============================

     If you have a HST only or v.32 only modem then this discussion doesn't
apply to you, you have no choice in what you use (I sure hope you picked
the right one).  You can skip ahead.  (If you are a modem expert I recom-
mend that you do read the detailed explanation on this decision.  It's
interesting that it's not really the link protocol but the error control
that provides for the slow down in unidirectional transfers with v.32bis.)

     Actually, the decision here is quite easy.  If you spend the majority
of your time downloading files (or upload but rarely have the need to do
both at the same time), choose HST.  HST is faster.  You can reach 1740 cps
in either direction using HST whereas you can only get about 1700 cps using
v.32bis and 1100 cps with v.32.

     If you plan to use HS/Link to Up and Download files simultaneously
then there is no choice, v.32 is the only way to go.  HST is not designed
to do this.  You can reach 1680+ (averaging about 1650 though) cps in both
directions simultaneously when using HS/Link and a pair of v.32bis modems. 
(More on HS/Link later.  Suffice it to say that, obviously, HS/Link allows
you to simultaneously upload and download files).

     If you don't transfer files then it really doesn't matter which you
use.  v.32 provides a quicker, crisper feel to your typing and on-line
games may respond noticeably quicker but not significantly.  Both HST and
v.32 provide good control over noisy line conditions.

     You say you have a Dual Standard and are calling another Dual Standard
and want to use HST instead of v.32bis?  There is an easy solution.  If you
would like to disable v.32 then simply use "ATS27=4".  This will disable
v.32 and v.32bis until you enter a "ATS27=0" to re-enable it.  The B1/B0
setting has no effect when you are calling, only answering.  When answer-
ing, B0 will allow a v.32 connection while B1 will not.


Using Compression: v.42bis versus MNP 5
=======================================

     Here you have two decisions, do you use compression and if so, which
one.  In the past I've recommended against using any data compression. 
After LONG and detailed reexamination of my own download and upload experi-
ences I am ready to suggest differently.  This is not a full reversal.  If
you want to get THE FASTEST transfer times (on compressed files) out of
your modem, do not use compression.  It's as simple as that.  If you don't
mind slowing down by approximately 1-5% (but an average of 2%) then use
v.42bis.  Unless you are only transferring non-compressed files (and cannot
use v.42bis) or do not perform file transfers, do not use MNP 5, the
slowdown is up to 45%

     O.K. Alex, you say to me, why is all this so?  Doesn't it make sense
that compressing data before it's sent will speed up my transmissions?  You
are, of course, right (the customer is always right).  I say to you, THAT
is why BBS's (among other reasons) have all their files in .ZIP format (or
.ARJ, .ARC, .LHZ and others).  A ZIP file is already compressed and far
better than v.42bis could EVER hope to do.  When you try to compress an
already better compressed file you just end up incurring (and passing
along) extra overhead.  This slows down transfers.  v.42bis is designed to
detect a compressed data packet and minimize the overhead sent with such a
packet, MNP 5 cannot do this.  This means that if you transfer a compressed
file with MNP 5 your speed will drop dramatically.  How much?

     Transferring a typical ZIPped file using HST and Ymodem-g.  Without
data compression this file will transfer at about 1730 cps.  Using v.42bis
it will go at about 1700 cps or less and with MNP 5 this same file will
move at less than 1550 cps (in some cases as slow as 1000 cps).  (Reduce
these figures by about 2.5% for a connection using v.32bis.)

     If you decide to use compression, which should you use?  v.42bis is
the better compression, simple as that.  MNP 5 can provide up to a 2 to 1
compression ratio on average.  v.42bis can provide up to 4 to 1 (but
usually closer to 3 to 1).

     You may be saying to yourself, hey, 1700 versus 1730 isn't so bad. 
Why don't I use v.42bis and just live with the 2% loss of speed.  That is a
perfectly valid argument and is up to you how important 2% is.  If it's a
long distance call it may be worth considering, if it's a local call don't
lose sleep over it.  Also remember, if you are using v.32bis, reduce this
by an additional 2.5% to accommodate in reduced efficiency of the LAPM
error control protocol over HST error control.  Now you are nearly 5%
slower.

     How fast is compression, really?  Well, I have transferred several CAD
files, each over 4 megs in size, using HST & v.42bis at a speed of just
under 3835 cps.  I have transferred (as par to testing) the PC Board BBS
documentation file, PCBOARD.DOC, at a steady 3800 cps.  The same files
under MNP 5 scored about 2850 and 2550 cps respectively.  Without compres-
sion, 1730 cps average.

     Now you are saying, Hey!  I want to get 3835 cps downloading .ZIP
files, why can't I do that.  Well, instead of telling you to reread the
above paragraphs and quite dreaming I'm going to make you feel better and
tell you that in fact, you are actually going even faster!  If you were to
transfer the PCBOARD.DOC file after ZIPping it you would be getting about
6400 cps!!  How?  Well, as I said, a ZIPped file is better compressed then
transferring an non-compressed file with compression.  This means your real
throughput is higher than the simple ZIP file transfer throughput.  Look at
the detailed explanations for the math.  You will be surprised.


WHICH TRANSFER PROTOCOL?  Ymodem-g vs Zmodem-90 vs HS/Link vs others
====================================================================

     Again, I'll give you the easy answers and if you want details, look in
the detailed explanation area.  The 'others' category includes such golden
oldies as Xmodem, Kermit and hacks of other protocols as well as others
that claim to be faster or are around to satisfy special applications.

     Ok, let's jump right to it.  The fastest transfer protocol is Ymodem-
g.  The fastest implementation of this protocol I've ever used is part of
the DSZ (and GSZ) driver from Omen Technology.  To use this protocol
requires registration of DSZ or GSZ.  This is such a good performer (al-
though the documentation and user interface sucks) that I can recommend it
worth your while to register this shareware product.

     Zmodem is also from Omen Technology.  Unlike Ymodem-g, Zmodem was
written by Omen.  No one writes a better Zmodem then Omen and the only true
implementation worth talking about comes from the DSZ and GSZ drivers.  The
internal versions and hack version of Zmodem I've tried have never per-
formed as well as the Omen version.  Now there is a version of Zmodem
called Zmodem-90 (nicknamed MobyTurbo by it's author).  This version is
even faster and comes closest to the times reported by Ymodem-g.

     Zmodem is worth considering even if it isn't as fast as Ymodem-g for
several reasons.  Like Ymodem-g it is a batch protocol, which means you can
transfer several files in a row and both do not require you to enter the
filenames, they are detected during transfer.  Zmodem, however, adds a
whole barrel of additional features.  Most notably, it has the ability to
recover from an error (which Ymodem-g cannot and is one of the reasons it
is so much faster) during transfer.  Also worth noting is that it has a
feature called Crash-Recovery.  This lets you resume downloading a file
that got cut-off prematurely without having to start back at the beginning
of the file.

     The other protocol to consider is HS/Link.  This is a brand new
protocol and as of this writing is only at version 1.00.  I followed this
protocol through beta testing and knew that it help promise as it addresses
a feature of modems that has long been ignored.  You will only want to
consider HS/Link if you have a Courier capable of v.32 (the Courier Dual
Standard and Courier v.32 both do, the HST does not) and you perform both
uploading and download of files.  While this protocol can transfer in one
direction only (and does so nicely), you'd be much better off using Ymodem-
g or Zmodem-90.

     HS/Link allows you to upload multiple files and download multiple
files in both directions at the same time at speeds that are very close to
what Zmodem can do in just a single direction.  Think of the benefit on a
BBS.  You are going to be spending the next 20 minutes downloading so why
not upload something at the same time.  You get upload credits, the BBS
gets new files (which are always needed) and you are pushing the envelope
of modem communications technology (the air sure is clear up here).  Unlike
the only other bidirectional protocol I've found out there, BiModem,
HS/Link is very easy to use and quite fast.  HS/Link has error correction
and crash recovery like Zmodem.  It is available as shareware and has only
it's display slightly crippled, not it's performance.  That said, I must
also comment that it is well worth the registration fee and I suggest that
you do register and help this protocol improve.

     To summarize:

     Fastest -> Ymodem-g
     Fault tolerant -> Zmodem-90 (MobyTurbo)
     Bidirectional -> HS/Link

     Choose depending on your requirements.


A NOTE ON SERIAL PORTS AND THE 16550 UART
=========================================

     The UART is the chip that handles data between your computer and your
modem.  If you have an internal Courier modem, you have the best UART in
the market already installed, pat yourself on the back.

     If you are using an external modem, you have to plug into a serial
port via a cable.  This serial port is either on a plug-in card in your
computer or on the motherboard itself.  Most serial ports use a quite
inferior UART chip.  This chip doesn't handle high speeds very well.  Even
if you have a very fast computer, sometimes the UART still can't keep up
and loses some of the data coming in your serial port.  This will cause
errors that will abort your Ymodem-g transfer or severely slow down your
Zmodem and HS/Link transfers (other protocols suffer as well).

     If you replace the UART in your system with a NS16550AFN UART chip
(which, by some miracle, is a straight forward, pin-for-pin replacement)
you will find this situation much improved.  Both DSZ (GSZ) and HS/Link,
discussed above, support this chip.  Your transfer speeds will improve
slightly.  More importantly, your computer should be able to handle the
high speeds correctly, even if you multitask or have a slower computer.

     You can get this chip from electronics mail order shops like Arrow
Electronics.  You can also order the chip (by itself or already installed
in boards) from Rusty 'n' Edie's BBS (call (216) 726-2620 data).  Just look
around, it is well worth the search.  If your serial port is part of the
motherboard, it may actually be worth it to disable that port and use an
add-on board.  More on this in the detailed explanations section that
follows.  The chip has "16550" right on it so you an identify it easily.


                DETAILED (SOMETIMES TECHNICAL) EXPLANATIONS
               ============================================



     Who is Alex Boge?  Well, I'm a 14 year computer veteran.  I've worked
on a large variety of computer but mostly on PC's based on MS-DOS (uh,
that's 'IBM Compatible' to you uneducated lugs out there).  I have been
using modems for all 14 of those years.  My first experience was at 300
baud on a teletype and now I'm at 14,400 bps on a 80486.  I've come a long
way baby!  I don't claim to know everything (not publicly at least) but I
do know enough that I can write this document.


THIS DOCUMENT
=============

     In producing this document I draw upon years of experience in the PC
BBS scene, all around the USA and outside.  To produce the figures and
reach the conclusions presented here I downloaded over 500 megabytes of
files and uploaded over 200 megabytes.  Much of that in the last few months
alone.  This is the third revision of this document, it is a complete
rewrite.

     This document is UP-TO-DATE.  I am talking about v.32bis and v.42bis
technologies.  The modem I'm using right now is the latest generation US
Robotics Dual Standard.  It's got all the buzzwords: HST, v.32bis, v.32,
MNP 2-5, LAPM, v.42bis and all the other lower speed protocols which I
won't even bother to mention.  If you are running under 9600 bps then I
don't have time to wait for you...get real, go 14.4!


SETTINGS
========

     Here is the result from an ATI4 command on my Dual Standard.  It
should be the same (except the title, and perhaps the B0 setting).  If you
have an HST only then instead of a B0 you will have a B1.

     On my settings you will see just a couple of differences from those I
suggest at the beginning of the document.

     M3 keeps the speaker quiet during dialing and only on during the phone
call and link negotiation (you can hear the difference between a quick HST
connection and the much longer v.32 negotiation).  &A3 reports all the
protocols in use on this connection on the CONNECT line.  I use &K0 because
I want the fastest possible transfer speeds, you may select to use &K3
which will allow v.42bis compression but never MNP 5.

ati4
USRobotics Courier 14400 HST Dual Standard Settings...

   B0  C1  E1  F1  M3  Q0  V1  X4
   BAUD=38400  PARITY=N  WORDLEN=8
   DIAL=HUNT   ON HOOK   TIMER

   &A3  &B1  &C1  &D2  &G0  &H1  &I0  &K0  &L0
   &M4  &N0  &P0  &R2  &S1  &T5  &X0  &Y1  %R0

   S00=000  S01=000  S02=043  S03=013  S04=010
   S05=008  S06=002  S07=060  S08=002  S09=006
   S10=007  S11=070  S12=050  S13=000  S14=000
   S15=000  S16=000  S17=000  S18=000  S19=000
   S20=000  S21=010  S22=017  S23=019  S24=150
   S25=000  S26=001  S27=000  S28=008  S29=020
   S30=000  S31=000  S32=001  S33=000  S34=000
   S35=000  S36=000  S37=000  S38=000

   LAST DIALED #:

OK

While we're talking about AT commands, try ATUSR.

     I'll explain some of these settings here.  I don't cover them all
because most settings don't affect performance.  Several may be different
depending on your phone system, computer system and other local conditions.

     B0 or B1
     ========

     This setting is B1 on an HST only modem and B0 on a v.32 only modem. 
The Dual Standard can use either.  This setting only affects what a Dual
Standard will do when answering a call from another modem.  If you use B1
then only a HST link will be negotiated.  If you use B0, then your Dual
Standard can answer calls in v.32(bis) mode from v.32 modems.

     &B1
     ===

     Here is an important setting.  Your Courier modem has the ability to
use two different speeds at the same time during communications.  There is
the speed at which the modem talks to the other modem (this is the DCE/DCE
rate or modem speed) and the speed at which the modem talks to your
computer (this is the DCE/DTE rate or terminal speed).  Both are measured
in Bits Per Second, or BPS.  Do not confuse this with baud, they are
different.

     You will be using the fixed DTE mode.  This means that regardless of
what speed the modems are talking to each other, your computer and modem
will always communicate at the same, higher, speed.  We use a high speed so
that the modem doesn't have to wait for the computer.  Your computer is
almost always faster than the modem (except in the case of really slow
computers) so this is desirable.  When you use compression, sometimes more
data comes in then you might think.  Two modems communicating at 14,400 bps
can transfer at a rate of up to 3840 cps, that's 38,400 bps.  You'll need
every bit of speed your serial port can provide.  That is why you want to
have your communications program port speed set to 38400 bps.  This way
your more will never overrun your computer.

     By default (&B0), when the modem connects with another modem, it
changes the speed that it communicates with your computer to match that of
the modem link.  If you connect at 2400 bps, then the serial port speed
changes to 2400 bps.  Using &B1 overrides this and forces the DCE/DTE speed
to stay at 38400.  Newer Courier modems will override the &B0 setting and
force a speed of 19200 bps when making a 12000 or 14400 bps connection.


     &C1 and &D2
     ===========

     These settings don't affect performance but make the Courier to
accurately report a connection to another modem and allow you to hang up
your connection quickly.

     
     &H1 and &I0
     ===========

     These two settings define flow control.  The &H1 is most important. 
It tells the modem to use hardware flow control.  At the speeds we are
working, hardware flow control is absolutely necessary to keep each modem
from overrunning the other (sending data too quickly in one direction or
the other, or both).  While you can use software (XON/XOFF) flow control,
it is no where near as quick and will probably not be up to the task. 
Also, it will lower performance.  You must set your communications program
to use hardware flow control as well.  It may be called CTS/RTS (or simply
CTS) flow control.  &I0 turns off software (XON/XOFF) flow control on
received data, this sort of control is unnecessary and adds overhead.  See
&R2)


     &K3 is discussed in the section about compression.
     ===


     &M4
     ===

     This setting controls error correction.  The &M4 setting is most
flexible.  If it is possible to use error correction, the modem will.  If
not, it will connect anyway and continue.  Note, it is required to have an
error correcting connection in order to communicate over 2400 bps.  If you
turn off error correction with &M0 then you will never connect over 2400
bps.  The only time I ever turn this off (&M0) is when I'm calling some
lame board that has lamer modems that choke during error correction
negotiation and fail to connect.  Turning this off will make for a quicker
connection if you know the modem you are calling doesn't use error correc-
tion.  Error correction is negotiated depending on the link protocol.  If
the protocol is HST, the HST error correction is used.  If it is v.32 then
LAPM is used.  Otherwise, LAPM is tried first then MNP 4, 3, and 2. 
Courier modems do not use MNP 1.  Compression will not be used unless error
correction is also used.


     &N0
     ===

     This setting permits the modem to negotiate for highest speed.  If you
set this to any other value, then only the speed for which you set it will
be permitted.  If the other modem doesn't support that speed then the
connection will not be made.  Using &N0 also activates the fallback and
fall forward features of the Courier modem.  Fall forward is not found in
other modems.  Most modems will fallback the connect speed if line condi-
tions are poor. Courier modems use Adaptive Speed Leveling (ASL) which
continue to monitor line conditions and when they improve, bring the speed
back up.


     &R2
     ===

     This activates hardware flow control for use on received data.  This
is as important as the &H1 setting.  Data coming in from the other modem
can sometimes overrun the receiving modem and/or computer.  This signal is
lowered when the modem receive buffer is nearly full and is only raised
when the buffer is near empty again.  This signal is controlled by both
your computer's serial port (in turn controlled by your communications
program) and the modem itself.  There can be a situation where your modem's
buffer is not yet full but your computer is not ready to receive data.  For
example, if you are multitasking and the computer is busy accessing the
disk for some other program.  It may spend so much time doing the disk
function that it can't keep up with the steady flow of data from the modem
so it tells the modem to wait for a moment.  Flow control is necessary at
the speeds we are dealing with.  If this setting is ignored then you will
almost certainly fail during downloads.


     DIP SWITCH 9 - DOWN
     ===================

     I recommend changing your DIP switch number 9 to the down setting. 
The reason for does not effect performance, but gives you an opportunity to
examine the condition of your connection while still connected.  With
switch 9 in it's default position, up, when you type the modem escape
command, three plus signs with at least half a second of nothing before and
after, the connection is hung up and you are returned to command mode. 
With it in the DOWN position, when you do this, you are returned to command
mode but still connected to the other modem.  While in command mode there
is little you can do but one very useful command.  Use ATI6 while in
command mode to view the link diagnostics screen.  Here you can see exactly
how many characters you've sent and received since connecting.  You can
also see what speed you are currently communicating at (which could be
lower because of bad line conditions and automatic fallback).  You can see
how many errors error correction has corrected.  By looking at this screen
you can see if the sudden slow down you had in the last file was because of
line noise.  This will also tell you how the connection was broken after it
is broken.  Was it a burst of line noise or did the sysop hit "Logoff". 
Look the ATI6 command up for an explanation of the various fields.  It's
too much to repeat here.


     BLINKY LIGHTS
     =============

     What do all those lights on my external HST mean anyway.  Well, mostly
I'd tell you to look in your manual but there is something things you
should know without having to dig this up.

     When the ARQ light is lite you have a connection with Error Correction
(either LAPM or MNP).  If the HS light is lite then you have a connection
at over 2400 bps.  The OH light is on as soon as the modem starts to dial
and goes off when it hangs up the phone line.  The CD light goes on when
the modem is connected to another modem.  This pretty obvious stuff.

     When the ARQ light is flashing, error control is functioning.  I mean,
that an error has been detected and is being corrected.  ARQ stands for
Automatic Repeat Request (got me why they didn't call it ARR) which is
generic for error correction.  When the MR light is flashing, the modem is
retraining.  That means that it is either falling backwards in speed due to
excessive line noise or errors or it is falling forwards because conditions
have improved.  This is the time to use your +++ then ATI6 to see what
speed you are at.  Perhaps you've fallen so far down that it would simply
be better to hang up and call back with a cleaner connection.

     If you are not connected to another modem then the AA light is lit if
you are in auto answer mode.  When you connect, the modem that has the high
speed channel (when in HST mode) has the AA light lit.  If you are down-
loading, then it will be off.  If you are uploading, after a brief moment
(the MR light will flash while the HST reverses the line) the AA light will
lite up telling you that you now have the full speed channel.  v.32 modems
do not exhibit this behavior as they never need to.


     TERMS/GLOSSARY
     ==============

     Here is a rambling guide to all the different terms that I used in
this document.  I'm putting it here because it's about time I explained
some of these things and you'll need to know what they are before you can
tackle the stuff that follows.

     PROTOCOL - This is a fancy term to use when you want to say, how
something talks to something else.  We use it here when we want to describe
how one modem talks to another.  Does it use v.32 or HST.  A protocol is
just a predetermined, ordered way of communicating that all parties agree
on ahead of time.  It is fixed.  The specific protocol used can be negoti-
ated prior to it's use, all modems do this.

     LINK NEGOTIATION - This is what goes on first when two modems begin
talking to each other.  The squeal and squawks you hear when a modem first
begins to connect is the series of tones that the modems emit and detect
when trying to find out what the other side has.  In the simplest terms
it's something like this:

     "Hi, I'm a modem, are you a modem too?"
     "Yes, I'm a modem.  Are you a fax?"
     "No, I'm not a fax, are you?"
     "No, but I can talk using v.22, can you?"
     "Yes, I can, can you use v.22bis?"
     "Yes, I can, can you use HST?"
     "Sorry, never heard of it, how about v.32?"
     "Sure, I can do v.32, in fact, I can do v.32bis, can you?"
     "Wow!  So can I!  But first, tell me, can you handle LAPM?
     "I sure can."
     "How about v.42bis?"
     "My master won't let me the creep, wanna do it anyway?"
     "Naw, they'll catch us, let's just link and report back."
     "O.K."

     All you see, of course, is CONNECT 14400/ARQ/v32bis/LAPM.  Had the
devious modems misbehaved, there would have been a /v42bis on the end of
that string.

     Why do some modems croak when you use your mighty HST to connect with
a puny 2400 non-mnp modem?  Because their negotiations goes something like
this:

     "Hi, I'm a modem, are you a modem too?"
     "Yes, I'm a modem."
     Hmm, quiet type, "Oh, ok.  Can you talk using v.22?"
     "Yes, I can, can you use v.22bis?"
     Maybe this guy isn't too bad, "Yes, I can, can you use HST?"
     "Huh?  What?"
     oh-oh, "Can you use MNP 4"
     "Duh...wha?"
     "How about MNP 3 or 2?"
     "I'm so confused."
     <click> "NO CARRIER"
     How rude.


     LINK PROTOCOL - This is what is first negotiated during Link Negotia-
tion.  This protocol is the means by which the two modem are actually
talking to each other.  It is the basis on which everything else is built. 
Mainly, it defines the speed of the two channels of communications.  I'll
mention the ones we're most interested in.

     HST - this has 14400 bps in one direction (the one most heavily used)
     and 450 bps in the other.  (Old HSTs may only have 9600).

     v.32 - this has 9600 bps in both directions.

     v.32bis - this has 14400 bps in both directions.

     (v.22bis - 2400 bps in both directions.)

     Note that v.42 is not listed here.

     You may sometimes see BBSes advertising 19.2K or 38.4K HST, call here,
we have the best Warez!  These are signs of stupid/ignorant people.  Their
I.Q.'s are reflected in their insistence on spelling words that end in "es"
with an "ez".  Those speeds are the DCE/DTE port speed.  There is no such
thing as a 19.2K HST modem.  Ignore these claims as you should claims that
Elvis lives in Kalamazoo (he lives in Akron, of course).


     ERROR CONTROL PROTOCOL - This is the means by which the modems will
correct errors during transmission.  When one modem detects an error,
usually caused by static on a phone line, it will send a request to the
other modem to repeat the bad packet of data.  When you see the ARQ light
lit and get a /ARQ on the CONNECT line, you have an error controlled
connection.  The Courier line of modems has three, not two, types of error
control available for it to use.  Error control is not available for
connections under 1200 bps.

     HST - Yes, there IS an error control protocol called HST as well as a
     link protocol.  This protocol is a slightly more efficient version of
     MNP 4 also modified for the asymmetrical modulation used by HST modems
     (that's the high speed/low speed channels difference).  This is a very
     low overhead protocol.  The performance of this protocol is similar to
     MNP 4 (see below) and actually yields higher than normally expected
     throughput for a given data rate.  For example, although the link is
     at 14400 bps, which would yield, at 10 bits per character (8 bits per
     byte, plus 1 start bit and 1 stop bit), an expected maximum rate of
     1440 cps, it in fact returns throughput as high as 1740 cps.  And the
     1740 figure includes overhead for the transfer protocol (Ymodem-g).

     LAPM (Link Access Procedure for Modems) - This is part of the v.42
     recommendation.  It is used when an HST link is not made and is picked
     over MNP.  It is NOT as efficient as the HST error control protocol. 
     THIS is why a HST download at 14,400 bps is faster than the exact same
     download using v.32bis.  v.32bis cannot use the HST error control
     protocol, only a HST connection can.  This is why an HST connection is
     preferred over a v.32bis when doing transfers in one direction only. 
     LAPM provides a throughput of only about 118% of expected.  It is
     argued that LAPM is more robust than MNP and would fair better during
     a cellular phone call.  I have no evidence to support this (and ask,
     what about MNP 10?).

     MNP 2-4 - The modems will attempt to use the highest version of MNP
     they can, as each level is better than the previous.  At level 3,
     performance is break even with a non-error control connection.  At
     level 4, performance is actually better, yielding about 120% of the
     normal expected throughput (i.e., a 2400 bps connection yields about
     280+ cps transfer versus the expected 240 cps maximum at MNP 3 or non-
     error control).

     Fortunately, there is little choice here.  You either have error
control on or off.  You cannot select one over the other.  The Link
Protocol will determine which is present on the other end and respond in
kind.  The good part is that by having all the options in one box you are
sure to get the best possible connection with all other modems.


     v.42 - v.42 by itself is not a protocol, instead it is a (quoting the
HST manual now): "standard for modem communications that defines a two-
stage process of detection and negotiation for LAPM error control."  I'm
not sure why they didn't call LAPM v.42 or v.42 LAPM.  It's too bloody
confusing.  Basically, forget v.42.  There is LAPM (the error control) and
v.42bis (the compression), just remember those two.  Note also, v.42
supports the use of MNP levels 1-4 when a LAPM error control cannot be
negotiated.  This is what allows v.42 compliant modems to connect to older,
MNP only modems.  This is the wisest part of the v.42 standard.


     COMPRESSION PROTOCOL - The Courier modem supports two types of
compression, v.42bis and MNP level 5.  v.42bis is the newer and more
efficient protocol.  MNP 5 was first but is not nearly as good.  If the
other side has both protocols (and you are using compression) then v.42bis
will be picked over MNP 5.  In cases where the answering side has MNP 5 but
not v.42bis you can have your Courier not use compression for this session
but be ready to make a v.42bis link whenever next possible by using the &K3
option.  This option only permits v.42bis compression and denies the less
efficient MNP 5.  If you are going to use compression, this is a very
desirable feature and are, as far as I know, exclusive to the Courier line
of modems.


     TO USE COMPRESSION OR NOT TO USE COMPRESSION
plus WHICH COMPRESSION TO USE IF I DO
=================================================

     This is one of the "fun" parts of this document.  Readers familiar
with my first two revisions of this document (this is a complete rewrite,
by the way) will recall that in those I recommended flatly against using
any data compression.  I still maintain that if you want the very fastest
transfers possible you should not use data compression when transferring
compressed files.  Of course, if you were transferring non-compressed files
I would easily suggest using v.42bis.  But, read on, there are many things
to consider.

     First, what do you really want?  Do you want to go fast, really fast. 
Do you intend on performing transfers in one direction at a time?  Are you
transferring compressed (ZIP, ARC, LZH, ARJ, GIF) files?  If you answer yes
to all of these, do not use any compression and use HST whenever possible. 
This will result in the fastest possible transfers, bar none.  I'll stake
my reputation on it (and have).  If you use Ymodem-g (as provided by DSZ or
GSZ from Omen Technology and use a 16550A UART) for your transfer protocol
then you can except your transfers to reach as high as 1740 cps.  Higher
than that has been recorded but I attribute to the relatively coarse
resolution of the PC timer (approximately 1/18th of a second) used in the
calculations.  Some people have reported faster times with other protocols
but after I timed them using external timers and higher resolution hardware
clocking methods I've discovered that the authors of these protocols, shall
we say, enhanced their calculations just a tiny bit...

     If you don't mind loosing just a little speed, we're talking about 2%
here, then go ahead and leave v.42bis on all the time.  Use the &K3 I
recommend at the beginning of this file.  It will screen out MNP 5 which is
deadly slow but let v.42bis calls connect.  Instead of 1740 cps as a
maximum, expect 1710 as the maximum with the average being just under 1700. 
On GIF files you may even see just a bit higher, but there is a lot that
could effect that.  For example, non-interlaced GIFs transfer slightly
slower than interlaced ones.  Dithered images transfer slightly slower than
non-dithered.  Don't worry about it too much, it's only by a few cps.

     Do you enjoy waiting for your computer to grind through a download? 
Got nothing better to do then watch your modem lights flicker?  Go ahead,
use MNP 5.  It's your time, not mine.  But don't do it on boards I call
please, I actually dislike busy signals!

     Lemme draw ya a little chart that outta help a lot:

                          HST         v.32bis        v.32
                       14,400bps     14,400bps     9600 bps
                    ͻ
               None   1710-1740    1670-1700    900-1120   
                    Ķ
            v.42bis   1650-1710    1620-1690    880-1110   
                    Ķ
              MNP 5   1450-1575    1400-1520     600-750   
                    ͼ
                           Transfer Speeds Using Ymodem-g
        
        Reduce these figures by about 3% if you are using Zmodem-90 (Moby-
Turbo) or HS/Link.  If you are using HS/Link and a v.32 protocol, then you
can expect to get these figures, minus 3-5%, in both directions simulta-
neously.  v.32bis can expect a combined transfer rate of about 3250-3350
cps, which is quite spectacular.  Remember to try to keep your upload and
download bytes about the same or one channel goes unused eventually. 
Performance only picks up by 1-2% in unidirectional transfer mode with this
protocol.



     TRANSFER PROTOCOLS - WHICH TO USE AND WHY
     =========================================

     If you want to move a file from A to B in as short a time as possible,
use Ymodem-g.  It's as simple as that.  Ymodem-g doesn't wait for an
acknowledgment from the receiver that data is getting there correctly, it
just keeps shoving it down the line, only subject to flow control (hardware
flow control is very important at this point).  Also, Ymodem-g uses only a
16-bit CRC, this is both faster and smaller than the 32-bit CRCs used by
Zmodem and HS/Link.  Ymodem-g is also very plain.  It has no special
features, it's very simple and works very fast.  Fortunately, it is also a
batch protocol and doesn't require user entry of file names to receive. All
these features combine to make it a very good choice for your default high
speed protocol.

     Omen Technologies has a shareware protocol driver called DSZ (and a
slightly more "graphical" version called GSZ which contains the same
protocol's but with a nicer display and, fortunately, the same command line
interface) which provides the fastest version of Ymodem-g I've been able to
find.  This driver also provides the only source for Zmodem-90.  This makes
this driver very valuable to have.  In order to use the Ymodem-g portion,
you have to register this program.  It is shareware well worth the invest-
ment, I suggest it for anyone into modeming.  The Zmodem-90 is free.  Make
sure to get the latest version.  Once you register, you get all updates
free via BBSes around the world.

     Zmodem-90, or MobyTurbo, is a very powerful protocol.  It has many,
many features with terrible documentation and an equally annoying command
line interface (for example, everything must be typed in lower case.  Give
me a break, what is this, UNIX? ugh).  If it wasn't so good, no one would
use it but credit is given where credit is due.  It works and it works damn
good.  It is about 2-4% slower than Ymodem-g.  This is mostly due to the
fact that a lot more control information (which is all considered overhead)
is being transferred along with actual file data.  Zmodem uses 32-bit CRC
values, twice the size of Ymodem.  Also, it passes error control informa-
tion twice the size or more than that of Ymodem.  When an error occurs,
this is very useful to have around.  If you have an error free, reliable
link then this is all extra baggage that no one wants.  On my own system, I
use Ymodem-g for all my unidirectional transfers.  On the rare occasion
that an error occurs (9 times out of 10 this is because I did something in
another Desqview window that caused the computer to pause for an unusually
long period of time and therefore drop a character at the serial port that
the 16 byte FIFO buffer in my 16550A couldn't hold) I resume the download
at where it was aborted using Zmodem's Crash-recovery feature.  If you've
ever crashed just 5 Kb away from finishing a 5 megabyte download you'll
immediately appreciate the benefit of this.  The second most popular reason
for using Zmodem over Ymodem-g is that Zmodem is free, Ymodem-g isn't.

     When using DSZ (instead of GSZ), try to use the .EXE version.  It is
slightly faster at calculating the CRC but best of all, allows you to
specify a larger receive buffer, 16 Kb versus only 4 Kb with the .COM
version.  This alone can generate a few cps speed improvement.  GSZ.EXE has
these features and only comes in an .EXE form.  I would suggest to Omen to
drop the confusing double format (released in separate files too!) and
continue only on with the .EXE forms.  To use this larger buffer, you
should specify "-pB16384" on the command line.  The "p" must be in lower
case and the "B" in upper case.  Use this for both Ymodem-g and Zmodem. 
Also, to use Hardware flow control you must specify "handshake on" on the
command line too.  This can be abbreviated to "ha on" in lower case only.

     If you have a v.32 modem, especially a v.32bis, and you are planning
on both uploading and downloading from the same place then bless the
gentleman who wrote HS/Link.  The new protocol is exactly what Dual
Standard owners around the globe needed.  It lets you perform simultaneous
uploading and downloading at full speed ahead (about the same or slightly
slower than Zmodem-90) with a very easy, friendly user interface.  If you
have a Dual Standard and HS/Link, there is no reason not to upload to your
favorite board.  Support the BBS ideal, spread good files everywhere. 
You're going to be on-line download anyway, why not stop being a leech and
contribute.  You'll gain respect from your peers (and more importantly, the
Sysop).

     HS/Link basically has all the features of Zmodem-90.  It is almost as
fast (but if you were doing unidirectional transfers, use Ymodem-g or
Zmodem-90 instead for max speed) but a whole lot friendlier to setup.  Once
setup, all three protocols are easy to use.  HS/Link also uses 32-bit CRC
for error control but that is redundant in a error controlled connection. 
It's there for 2400 bps users (they have 2400 in both directions so can
benefit from HS/Link as well, and at 2400, you need all the help you can
get!).  It can also perform crash recovery and it has the most efficient
error recovery schemes I've ever seen.  Instead of bringing the entire
transfer to a halt, rewinding past good data and resending from the bad
block forward, back over what was otherwise good data.  HS/Link requests
only the block that was bad, receives it whenever the sender has a pause to
do so, inserts it where it belongs and all in the meanwhile is speeding
ahead with the rest of the file.  Fantastic!  Let's hope that in later
versions the author finds some way to speed things up (perhaps with a 16-
bit CRC option and larger block sizes).  HS/Link also is shareware and I
would recommend you register it to promote further development.  However,
unlike DSZ, it is not performance crippled.  The shareware version provides
a full features set, only the display as somewhat affected.

     When using HS/Link, remember to increase the default block size to 4
Kb by using "-B4096" on the command line.  Additional performance MAY be
gained by using either -A or -W16.  I haven't finished testing these
options fully to recommend one over the other yet.  The -A turns off all
acknowledgments between blocks and -W16 increases the gap between acknowl-
edgments from the default 8 to 16 (the maximum).  We do this because
assuming error free conditions, we should not require acknowledgments. 
This should bring us closer to Ymodem-g performance by eliminating unneces-
sary overhead.




     This file was typed February 9-10 during a Diet Pepsi and Domino's
Pizza binge.  It was updated because of new data collected after updating
to a v.32bis Dual Standard modem.  The data presented in earlier versions
is still accurate except that now I have clarified my recommendations
regarding compression and have changed the default (easy) suggestion to
using v.42bis.

     This file was initially distributed by posting it on Rusty & Edie's
BBS in Youngstown, Ohio.  (216) 726-2620 - 120 lines/18+ Gigs.  This is the
friendliest, finest BBS in the world.  No doubt.  Drop in and say hi to
Rusty, Edie, Carl and the rest of the gang there.  You can e-mail me there
under the name Drestin Black (I check mail daily).  You can contact me on
CompuServe at ID 72470,402 (I check mail there weekly).  If you read this
far, you must have liked something so I like you.  You can call me voice
most anytime at (313) 781-2142 (until May 16, 1992).
