Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!gatech!amdcad!bandy
From: bandy@amdcad.AMD.COM (Andy Beals)
Newsgroups: comp.sources.d,comp.terminals,comp.emacs
Subject: Re: VT100's keeping up at high baud rates
Message-ID: <17160@amdcad.AMD.COM>
Date: Tue, 16-Jun-87 14:58:28 EDT
Article-I.D.: amdcad.17160
Posted: Tue Jun 16 14:58:28 1987
Date-Received: Sun, 21-Jun-87 07:28:47 EDT
References: <1149@carthage.swatsun.UUCP> <8601@tekecs.TEK.COM>
Reply-To: bandy@amdcad.UUCP (Andy Beals)
Organization: Advanced Micro Devices, Inc., Sunnyvale, Ca.
Lines: 54
Summary: Modern-day terminals are severely lacking
Xref: mnetor comp.sources.d:853 comp.terminals:313 comp.emacs:1166

A number of people have written how a number of terminals and terminal
emulator programs on micro-toys cannot keep up with a decent baud-rate.

In article <4101@teddy.UUCP> jpn@teddy.UUCP (John P. Nelson) writes:
>I once did some benchmarking that you all might find interesting.  I
>wrote a program which did nothing but fill a 80x24 screen with blanks
>several times, [...]  The only
>escape sequences I used were 'ESC [ H' to home the cursor after
>reaching the bottom, and the inverse video character attribute on/off
[every other pass]
>Flow control was enabled to avoid overruns.
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Thus invalidating the test.  I don't WANT the terminal to send flow-control.
In this day and age, where 64k x 8 of ram chips is cheap,  

TERMINALS SHOULD NOT HAVE TO SEND FLOW CONTROL BACK UP THE WIRE.

TERMINALS SHOULD HAVE LARGE BUFFERS SO THEY MAY BE OF REAL USE IN DAY-TO-DAY
OPERATIONS.  

The stupidest trend I've seen is the inclusion of microprocessors in
terminals.  Well, perhaps not, but the people who *program* the micros are
patently PINHEADS.  

The VT52 was a *wonderful* terminal.  Then came the VT100.  It could not
display characters as quickly.  Now we have the VT220, which is even slower
than the VT100!

Every time DEC (or someone wanting to be DEC-compatible) comes out with a new
terminal, it can not accept continuous data at as high of a rate as its
predecessor.  

>Anyway, true VT100's had a throughput just over 9600 baud.  VT101's had
>a throughput of only 4800!!!!  VT220's could go a sustained 19200 baud!

Your benchmark was invalid due to the fact that you enabled flow control.


If a terminal can't continuously display a couple of screens worth of text
while taking input without resorting to brain-damaged flow control then it is
no good.  


I would be interested in seeing a benchmark like the one that JPN did, but one
that records and reports "Terminal wimped out and tried to use flow control %d
times."  Perhaps one could be done using termcap and that way we all can test
the buggers.

-- 
55 is failing
70 is passing

Andrew Scott Beals, {lll-crg,decwrl,allegra}!amdcad!bandy +1 408 749 3683