Unix and Telebit modems

[lauren at rand-unix.arpa]

The message from ames!jaw pretty clearly hits the nail on the head.
To get decent performance from these modems is complicated--
just picking gigantic packet sizes and large windows doesn't
do the job.  The problems of system loading, flow control, dropped input 
characters, and other similar problems require very careful analysis 
to choose an "optimum" solution that will be generally useful.

An earlier version of the following message was sent to net.dcom
a few days ago.  Below is an updated verson:

----

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 running above real X.25/TCP links) designed 
to run on top of "conventional" error-free links generally perform badly 
in these sorts of situations, both due to modem characteristics and flow
control problems.  That is, when the underlying communications path
isn't already totally error-corrected and flow-controlled from computer
to computer, not just from modem to modem, there's trouble with those
sorts of protocols.  In other words, protocols designed to run over 
X.25 or TCP links will not perform well when they're not actually being
run over X.25/TCP-type computer to computer error corrected and
flow-controlled links.  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 include continuing to use normal per-packet checking and
correcting but bumping software packet sizes to higher values as but one
step among a number of other changes that will be needed.  As I implied 
above, however, this is not as simple as it might sound, due to flow control
and other 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.  There are indeed rumors that these V.32 modems may
have problems on some sorts of telephone circuits.  This whole area
of Telebit vs. V.32, etc. is so volatile right now that I personally
feel the best solution is to just sit back and wait a while to see 
what happens and take a good look after the dust settles.

--Lauren--