From: utzoo!watmath!watcgl!dmmartindale
Newsgroups: net.unix-wizards
Title: Re: Padding on Ann Arbor Ambassadors &c
Article-I.D.: watcgl.78
Posted: Mon Dec 27 13:02:20 1982
Received: Tue Dec 28 04:51:52 1982
References: sri-unix.4922

Now, come on.  I have an Ambassador sitting in my office which runs at 19.2Kb
connected to a VAX running 4.1BSD, and our termcap entry specifies NO PADDING
for any function.  The terminal has Auto XON/XOFF set and whenever its
input buffer gets close to being full, it simply sends an XOFF to shut the
VAX up for a while until it can catch up.  If the terminal doesn't get too
far behind, then no flow control occurs.  The screen is always updated as
fast as the terminal is able.  If you use padding instead of flow control,
if you provide worst-case padding then most of the time the terminal isn't
getting commands as fast as it could be processing them.
Also, if you are running your terminal over a network of some sort which
supports flow control (e.g. Sytek localnet) the terminal will flow control
the network if it's necessary and the network can flow control the VAX if
necessary.  This seems better than using up network bandwidth transmitting
all that extra padding over the network.  (how many characters constitute
worst-case padding for a screen clear at 19.2K?)
Finally, reading through a copy of the new Ambassador manual not long ago,
I seem to remember that you could specify that rubouts were to be treated
as a real pad character, i.e. thrown away as they come out of the UART
instead of being put into the buffer.

	Dave Martindale