Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version VT1.00C 11/1/84; site vortex.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!vortex!lauren
From: lauren@vortex.UUCP (Lauren Weinstein)
Newsgroups: net.dcom
Subject: Re: modem evaluation - Telebit Trailblazer
Message-ID: <918@vortex.UUCP>
Date: Fri, 25-Apr-86 13:34:03 EDT
Article-I.D.: vortex.918
Posted: Fri Apr 25 13:34:03 1986
Date-Received: Mon, 28-Apr-86 05:02:32 EDT
References: <1703@sdcsvax.UUCP>
Organization: Vortex Technology, Los Angeles
Lines: 49

It would be best to wait for some time before drawing any final
conclusions one way or the other on the Trailblazer.  I've done
(and continue to do) various testing with a pair of these, and there
are a number of firmware problems in the unit that I've pointed out
to them and that they are working on fixing.  There have already
been significant variations between previous firmware revisions.
The "half-duplex" nature of the modem is actually less important than
one would think, since the modems buffer data in both directions and
perform a variety of other tricks.

However, a more serious problem relates to flow control.  While the 
modems do error correct (between the modems) in 9600 bps mode, data overflow
errors and other errors can frequently appear between the modems and the 
computers.  This is especially serious with many Unix systems, which
may have problems accepting longish streams of input even at moderately
low speeds on serial lines.  Since most standard Unix systems have
no serial line hardware flow control, and since ^S/^Q flow controls may 
be unreliable and introduce other problems, the flow control issues become 
quite sticky.  To get good performance, you end up needing to keep 
normal per-packet checking in programs like xmodem, uucp, kermit, etc.,
otherwise computer<->modem and flow control error rates get very high 
very fast.  Protocols (like for X.25/TCP links) designed for "conventional"
error-free links generally perform badly in these sorts of situations,
both due to modem characteristics and flow control problems.  Factors
such as system loading, type of serial port hardware, and a variety
of other issues all enter the picture.

I'm in communication with the manufacturer about the issues involved, and
have been discussing possible solutions with their engineers. 
Experiments are also being conducted involving minimal changes to software
to help avoid such problems, the most promising of which currently
would seem to be continuing to use normal per-packet checking and
correcting but bumping software packet sizes to high values.  This is
not as simple as it might sound, however, due to flow control issues.
In any case, it's being worked on.  Since the Telebit engineers
have been quite responsive, I expect to see future firmware revisions give
increasingly good performance, and other changes may also help solve some
of the more general issues associated with this sort of technology.

Whether or not all of this effort is worthwhile, in the light of
9600 bps full-duplex modems, is not clear.  I have yet to have
any hands-on experience with V.32 (Trellis coding) full-duplex modems, 
so I don't have any personal data on their performance characteristics
in various environments.  Presumably the pricing of V.32 modems
will fall, but the exact timing of such price changes is unclear
at this moment.  I guess the best solution is to just sit back
and wait a while to see what happens.

--Lauren--