Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!tut.cis.ohio-state.edu!mandrill!neoucom!wtm
From: wtm@neoucom.UUCP (Bill Mayhew)
Newsgroups: comp.dcom.modems
Subject: Re: BYTE high speed modem article and the Telcor Accelerator 2496MA
Summary: High baud-rate modems don't guarantee throughput
Keywords: BYTE magazine article, high speed modems, wild compression results
Message-ID: <1250@neoucom.UUCP>
Date: 2 Jun 88 18:21:07 GMT
References: <12997@shemp.CS.UCLA.EDU>
Organization: Northeastern Ohio Universities College of Medicine
Lines: 99


One thing that dismayed me about the article in the June 1988 issue
of Byte was that the authors failed to underscore how very
important it is to consider the modem and software together as a
system.  In fact, the Trailblazer's (just to mention one) special
internal support of the Christensen (xmodem) protocol, Kermit and
uucp g-protocol was not mentioned at all.

One thing that we've found is that turn-around delays on the
non-v.32 modems vary widely.  The turn-around delay as the modem
switches active communications direction can really devastate short
packet length protocols like Kermit and uucp-q, well .. xmodem too.
The delays between packets often are longer duration than the data
packets themselves.

Some software such as the newer incarnations of of Kermit and Relay
Gold (a commercial product) support long packets, and are thus not
bothered by turn-around delays.  These products (correctly??)
assume that most of the error correction can be handled by the
modem, thus the majority of packets won't need retransmission.

I personally have tried 3 v.32 modems:  the UDS, Concord, and
AT&T's.  I couldn't get the Concord to talk to the UDS or AT&T for
some reason.  The AT&T and UDS modems worked just fine.  We used
them under admittedly optimum conditions over a local dedicated
unconditioned twisted pair.  Concord claims that their modem has
much better than average performance, but we didn't notice any
better performance over UDS or AT&T.  Perhaps on bad lines...?  I'd
pick the UDS because it is substantially less expensive than AT&T.
Since the Concord would only talk to its own kind (at least in our
tests), I would avoid it.  v.32 modems seem to provide about 80 -
90% the throughput of a piece of wire with uucp under optimum
conditions.  I think the slow-down is due to the propagation dealy
inherent in the modulation and demoduation process.  This is were
Concord claims superiority in reducing delay.  Both the UDS and
AT&T modems had very nice front panel controls that were quite easy
to figure out even without much if any assistance from the manual.
In the case of the UDS, I didn't have to look at the manual at all
to get it properly set up.  With the Concord, there are a lot of
film-type pushbottons and a big bank of dipswitches in the back;
the manual is very necessary.  The AT&T has a constellation
generator card as an option, so that you can look at the carrier
pattern on an oscilloscope if that tickles your fancy; most people
won't care, I think.

I have tried 4 of the hybrid/v.29 modem:  Telebit, Racal-Vadic, US
Robotics HST, Microcom.  The Ralcal modem never did work quite
right; it was full of jumper wires on the PC board.  I think some
might have been missing or miswired, as the modem's operation was
too erratic.  In general, the Racal was difficult to set up and had
a cluttered front panel.  The US Robotics is a very nice modem and
quite attractively priced.  On uucp, the USR HST "only" managed
about 400 char/sec becuase the g-protocol didn't get along very
well with the delay.  It is my understanding that USR HSTs are used
quite extensively on the FIDO network, though I have no performance
data handy. The HST is qualitatively a very impressive performer
when I am on line at a terminal.  The response was quite zippy.
Once again, struck with bad luck, one of the pair of Microcomm 9624
modems died only about 5 minutes after we turned it on.  We didn't
get enough data to draw any conclusions.  The one remaining
Microcomm, however, did perform excellently at 2400 baud.  The
quality of consturction in the Microcomm product is quite good, so
I am surprised we had trouble.  Must be my luck.  My Telebit
experience has been with the version 3 firmware (Not the
Trailblazer Plus).  We've gotten nice results with it for UUCP with
xfer rates of up to 960 characters/sec between our sites.  The
version 3 firmware does have a fairly long turnaround delay when
typing at a terminal.  When using vi, I'd go at 2400 baud; save
9600/19.2 for reading news where not much interactiveness is
required.

Quite contrary to the findings of Byte, I've found that the Telebit
is the most tenacious of the lot we've tried.  Only sustained
shouting and dialing DTMF tones from an extension phone on the same
line would cause the Telebit to drop the connection.  All the
others would break the connection when dialing DTMF tones; usually
just lifiting the handset was enough to break the connection.  So
far we haven't had a Trailblazer drop a connection in PEP mode
under normal operating conditions.

Personally, I value the tenacity with which the connection is
maintained even more than the ultimate baud rate achieved.  A modem
that stays connected though heavy impulse interference at a lower
speed is likely to get better thoughput than one that has to keep
redialing the connection.

The figures provided by Byte are most welcome and useful, but they
really only tell a rather small part of the whole story.  My
recommendation would be to focus most on picking a particular
communications software package, and then go out and purchase
modems that work best with the product as per the software house's
recommendations.  Field experiences often tell much more than the
numbers.

--Bill
  wtm@neoucom.UUCP


"Look Ma, no '>'s!"