jdg (05/28/82)
It is true what you say about bit vs. char. transfer of stat muxs (some
TDMs use char a time also), but our investigation showed that it wasn't
always simple to account for the delay in terms of char transmission time,
buffer sizes, inter-mux protocol frame sizes, etc. We kind of expected
moderate delays for most of the HDLC type boxes on the market, but results
showed a high variance between brands (and even in different models within
the same brand!). In fact, we experienced very noticable delays with an
Infotron 480 but were pleased as punch with the Infotron 680 and we still
don't know why we get such differences in performance. It sounds as if
some complex iterplay between protocol type, frame sizes, buffering strategies,
etc. is at work.
There are also brands which feature a strictly FIFO approach to s.m.ing
and have a fast intermux protocol (2 byte packets--1 char & 1 address), and
their reponse is excellent as long as the buffers are small and you have no
bones about doing flow control. Problems arise with software that doesn't
respect flow control, e.g. EMACS, and things turn nasty rather quickly.
Finally a bit about our echoplexing: it seems that although it may have
started out as a verification technique it has been used for other purposes,
so mux echoplex isn't a total answer (you could just as easily turn echo off
and switch to half duplex at the terminal). For instance, typing your password
or someone's raw mode masterpiece..., it would be nice if there was a s.m.
that could be controlled via escape sequences or the like to control such
features but that raises the spectre of trnasparency issues. Think I'll just
buy me a TDM. Anyway, thanks for the responses & i look forward to any discuson
jesse goodman (hlexa!jdg)
BTL-HL (201)564-2223jdg (05/28/82)
P.S. I lost the name, address, and phone # of the person from U of N.C. could inconvenience that person to resend the above? thanks, jesse