Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!think!!rlk
From: rlk@.COM (Robert Krawitz)
Newsgroups: comp.sources.d,comp.terminals,comp.emacs
Subject: Re: VT100's keeping up at high baud rates
Message-ID: <5490@think.UUCP>
Date: Wed, 17-Jun-87 09:26:05 EDT
Article-I.D.: think.5490
Posted: Wed Jun 17 09:26:05 1987
Date-Received: Sun, 21-Jun-87 09:20:15 EDT
Sender: news@think.UUCP
Reply-To: rlk@THINK.COM
Organization: Thinking Machines Corporation, Cambridge, MA
Lines: 73
Xref: mnetor comp.sources.d:860 comp.terminals:316 comp.emacs:1174

In article <4116@teddy.UUCP> jpn@teddy.UUCP (John P. Nelson) writes:
]>>Flow control was enabled to avoid overruns.
]> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
]>Thus invalidating the test.  I don't WANT the terminal to send flow-control.
]
]You missed the point.  The point of this test was to see how fast the
]terminal could process data WITHOUT having to send Flow control
]characters.  Obviously, if the terminal sends an XOFF, the program
]could not possibly run as fast as the actual sending baud rate.  In
]other words, the test indicated that VT220s could keep up WITHOUT flow
]control at 19200 baud.  Of course, this is only true of the type of
]data that was tested: namely, no scrolling.

The fact that a terminal can run at an AVERAGE speed of, say, 4800 bps
does not mean that if you run it at 4800 bps it will not emit any flow
control sequences.  For example, suppose that a newline takes 5 ms
(this is silly if scrolling is not being done, but that is irrelevant;
in practice, other things like line deletion, etc. can take a lot of
time).  Further suppose that when the terminal is processing a newline
it is unable to accept any more characters (its serial port is
completely unbuffered).  Then the terminal must send an XOFF whenever
it receives a newline, since in 5 ms two or three characters would be
received.  Of course, when processing non-newline characters, the
terminal can accept data at a much higher rate, thus amortizing the
cost of the newline over a lot more characters...get the picture?

It's amazing how easy it is to avoid externally-visible flow control
if you really try.  The answer is buffering.  Several years ago, I was
working on an application that received data from a 1200 bps line.
Only problem was, this data was sent to a character-mapped screen with
no hardware support for scrolling, and scrolling took something like
18 ms.  The solution?  Use another computer (these were cheap) as a
front end whose only task was to take data from the serial port,
buffer it, and send it to the parallel port on demand.  Now, with no
hardware handshaking or the like, it was very easy to guarantee that
the serial port would be polled at intervals no greater than .1 ms,
which gave us a factor of 100 safety.  The real limitation on the data
rate was the processing, printer, and disk speeds of the application
computer (this was a line monitor).

Now, this was 4 years ago, using Exidy Sorcerers (Z-80-based micros
with no interrupts for DTR or the like) that cost about $150 at the
time.  This was not a sophisticated DTR-interrupt port, or DMA access
to the host, or anything of the sort, yet I could run this system with
average speed equal to peak, and the host never came close to running
into trouble.  We had a callup function available on the host, which
when used would stop all data flowing into the front end for perhaps a
few minutes.  This never caused any problems.  When data transmission
was resumed, the data would come flying onto the screen almost as fast
as a simple loop could send data to the screen (a few thousand
characters per second).  The equivalent hardware today would cost
perhaps $30 or so in quantity (a Z-80 with a couple of interfaces and
64K-ish memory), and with interrupt driven ports, even higher speeds
could be accomplished, for limited periods of time (until the buffer
filled).

Now, suppose I were in the market for a serial terminal.  Suppose a
manufacturer told me that I could run his terminal at a line speed of
38,400 and NEVER have to worry about flow control.  Suppose that the
cost of this terminal is $100 more than the cost of a simple terminal
that can run at 38,400 bps, but required XON/XOFF flow control at 4800
bps or greater.  Would I choose this terminal and pay $100 more?  You
bet I would!

The point of this flame is that with today's hardware (interrupt
driven I/O, hardware scrolling, DMA and the like) it should be a
simple matter to design an inexpensive terminal that can accept data
at tremendous rates and never have to use flow control, at least up to
76,800 bps.  There is simply no excuse for for XON/XOFF flow control,
except for the user who wishes to stop scrolling so s/he can inspect
the data.

Robert^Z