VT100's keeping up at high baud rates
j...@teddy.uucp
>> - terminal emulator
>>
>Heck, even the VT100 "emulation" inside a bona-fide _ V_ T_ 1_ 0_ 0 can't
>keep up at speeds of more than 4800 baud.
>
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, to time the terminal throughput (admittedly, without
scrolling, since that was not part of our requirement). 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
(toggled after every pass, so you could watch the progress of the
benchmark on the screen). I wrote an entire screen at a time to
minimize system overhead. Flow control was enabled to avoid overruns.
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!
Sorry, I don't have the program anymore, but i would be interested to see
similar benchmarks on other terminal types. Also, I would be
interested in seeing a "scrolling" version of this benchmark. Any
takers?
Stuart Lynne
>>> - Some (all?) PC/clones cannot keep up with speeds > 4800 baud in the VT100
>>> - terminal emulator
>>>
>>Heck, even the VT100 "emulation" inside a bona-fide _ V_ T_ 1_ 0_ 0 can't
>>keep up at speeds of more than 4800 baud.
>>
>
>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, to time the terminal throughput (admittedly, without
>scrolling, since that was not part of our requirement). The only
>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!
>
The problem with VT100 is mainly with scrolling!
From page 79 of the VT100 User Guide (2nd Edition, Jan '79):
"Fill characters are required to keep the VT100 synchonized with the
host computer when the XON/XOFF control codes are not used...."
The following is gleaned from table C-1 on the same page:
NEL, IND, LF, RI NEL, IND, LF,RI
Speed Smooth Scolling Jump Scrolling
19200 384 60
9600 192 30
4800 96 15
2400 48 11
1200 24 7
300 6 1
NEL Next Line
RI Reverse Index
IND Index
--
Stuart Lynne ihnp4!alberta!ubc-vision!van-bc!sl Vancouver,BC,604-937-7532
Andy Beals
emulator programs on micro-toys cannot keep up with a decent baud-rate.
In article <41...@teddy.UUCP> j...@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
j...@teddy.uucp
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>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.
w...@ho95e.uucp
>> - Some (all?) PC/clones cannot keep up with speeds > 4800 baud in the VT100
>> - terminal emulator
>>
>> speeds greater than 4800 baud! I have news for you: not all of them do.
There are two real issues here - how fast can a terminal go with flow control
enabled, and how fast can it go with flow control disabled. While it's nice to
have a terminal that can keep up with 19200 without flow control (i.e.
continuous text display), that's approximately 19200 words per minute, and
neither you nor I nor Evelyn Wood's mother can read that fast over sustained
periods. The reasons you'd want a terminal to go that fast without flow
control are either that you use a braindamaged computer which can't handle it,
or that you're using EMACS, and flow control ^S puts you into search mode.
(The solution there is to fix the software.)
As far as keeping up without losing characters, the PC's serial I/O capability
is pretty limited - you have to program well to make it go fast at all.
A couple years ago (when we got Datakit 19200 baud capability), I benchmarked
whatever terminals were aound to see whether to use 19200 or 9600.
time cat /etc/termcap
followed by some arithmetic. My 5420 (predecessor to the 5425, 610, etc.) did
about 8300 baud at 9600 and 8600 at 19.2. My 5620 (with the old firmware) got
about 6600 baud, and 2600 in layers. I'm since using better layers software,
but I don't really know how fast it is. We cranked an HP terminal to about
12000 baud.
One commentator here questioned the sanity of putting microprocessors in
terminals at all. I'm all in favor of it - assuming you provide decent
programming hooks, you allow the user to build a decent terminal environment.
An 80186 and 128K RAM shouldn't cost you more than $50, but that lets you build
windows, downloadable fonts, etc., and allows the user to undo any mistakes in
the original firmware.
--
# Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
mk...@teknowledge-vaxc.uucp
>have a terminal that can keep up with 19200 without flow control (i.e.
>continuous text display), that's approximately 19200 words per minute, and
>neither you nor I nor Evelyn Wood's mother can read that fast over sustained
>periods. The reasons you'd want a terminal to go that fast without flow
Actually, a lot of the time I don't want to read everything that's coming up
on the screen. What I really care is that things like screen refresh ought
not to keep me waiting. 19200 bps is 1920 chars/sec, which is one 24x80 screen
in 1 second (admittedly worst case). I consider that speed barely adequate.
Twice that speed would come close to being tolerable.
Mike Khaw
--
internet: mk...@teknowledge-vaxc.arpa
usenet: {hplabs|sun|ucbvax|decwrl|sri-unix}!mkhaw%teknowledge-vaxc.arpa
USnail: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
Robert Krawitz
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
John P. Nelson
>continuous text display), that's approximately 19200 words per minute, and
>neither you nor I nor Evelyn Wood's mother can read that fast over sustained
>periods. The reasons you'd want a terminal to go that fast without flow
>or that you're using EMACS, and flow control ^S puts you into search mode.
Actually, we had a different reason. We were developing a software package
which had to update the entire screen in response to a user's keystroke.
Updating the screen at 1920 characters per second is MUCH snappier than
updating the screen at 480 characters per second.
Also, I found that is was much nicer to use any full screen editor at the
faster speed. You were never waiting for the screen to be updated at a
full 19200 baud. Of course the XOFF/XON issue is not the point: The point
is "how fast can the terminal process display data".
- john nelson
jd...@osiris.uucp
disabled. That's why we bought them. The problem is that the $#%*ing
bridge box through which we connect to the network sends its own ^S/^Q's.
Oh, we tested the max speed using a direct connection to our vms machine which
really sends 19200 baud.
Josh / Spidey!
--
DON'T PANIC!!! \_\ /_/ Yes, it is
_[*]_ supposed to
A message from Spidey, and the Spidey Team. ------>>>> / / \ \ look like a
Reachable via UUCP: ...[seismo,mimsy]!jhu!osiris!jdia spider!
Steve Walton
>It's amazing how easy it is to avoid externally-visible flow control
>if you really try. The answer is buffering.
(I hate flow control flames.) As a naive user, what happens to the
contents of your enormous buffer when I hit an interrupt character
(^C)? Won't the contents of your buffer (which could be a few hundred
characters) get dumped to my screen? And how do I pause terminal
output? If your buffer recognizes ^S, what happens if it fills up
before I hit ^Q? (At 38Kbaud, 1 MB of buffer would fill in a bit over
4 minutes). And if your buffer recognizes ^S, then how do I use it as
an emacs command? Finally, if we just dump data fast into a buffer
which then hands it to a display (or a protocol-based file transfer
program) which can't keep up, eventually the buffer will fill up
anyway. What then?
Look, can we cool it? There are circumstances where you just
*have to have* in-band flow control, and like it or not, ^S/^Q are the
universal standard for it. The *only* place this matters is Emacs
flavors which use these as commands, and said Emacsen are sufficiently
customizable to allow them to use something else if you need the flow
control.
I've directed followups to comp.terminals only.
Steve Walton, guest as wal...@tybalt.caltech.edu
AMETEK Computer Research Division, ametek!wal...@csvax.caltech.edu
"Long signatures are definitely frowned upon"--USENET posting rules
Mark W. Eichin
I worked with Visual 200 terminals-24x80, lots of PF keys, keypad,
smooth scroll (REAL smooth scroll, by pixels), nice heavy feel...
AND IT DID 19200 baud W/O FLOW CONTROL!
It was PERFECT at 9600baud, but at 19200 it didn't scan the keyboard
as often. This was tested by driving it with a tight machine language
loop on a 6Mhz z80 system, directly controlling the UART. You got one
keyscan per 500-600 characters. Enough, but a bit confusing when
trying to pause it. (We used ^S/^Q as HUMAN flow control - when the
USER couldn't keep up, hit ^S to pause it.)
This terminal had a 2Mhz Z80 inside, or maybe two of them... a bunch
of roms, too.
We had the roms set to have the WordStar sequences in the PF keys;
this worked well, since we could program the 20 keys, 20 shifted keys,
PLUS the 15 key keypad (toggled between numbers and functions, and
which one was shifted.)
I don't know if these terminals are still around. We had difficulty
getting them after a while. They may have (shudder) EVOLVED since then...
/Happy Hacking........\\.............Mark Eichin/
<eic...@ATHENA.MIT.EDU><SIPB member & Watchmaker>
je...@oliveb.uucp
>if you really try. The answer is buffering. Several years ago, I was
Nothing less than an infinite amount of buffering will guarante that
flow control is never needed. (Assuming that the terminal can't process
the characters at full speed.)
For any amount of buffering you can devise a sequence of characters, say
insert line at the top of the screen, and repeat them continuously.
This will eventually fill up the buffer and either drop characters or
require flow control.
Granted that most applications do other things besides scrolling the
screen and this will usually allow the terminal to catch up. Also they
seldom send continuous data without any pauses for input. But it
sometimes does happen.
Besides, large input buffers present their own problems. Have you ever
tried to pause a display that has lots of buffering? If you signal the
host to stop sending then what you want to see can scroll off the screen
because of the local buffer. Most such terminals resort to a local
pause instead of depending on the host to pause output. But, unless you
also signal the host, your buffer will fill and overflow. So, you still
have to have some kind of flow control.
ji...@iscuva.uucp
>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.
Yassir! I've just finished writing a H19-like terminal emulator for one of
our products that keeps up fully at 9600 baud (doesn't sound like much? well,
it's a graphics-only product with 38K of RAM for the video). It's written in
C with choice bits in assembly (68000). I ended up using a 16K input buffer
just 'cause it was there, tho' it doesn't need it that big. What made it all
work is that I separated the input processing code from the display code, and
the input processing code notices when scrolling is getting behind, and tells
the display code to start scrolling bigger chunks when necessary. I got lazy
and only implemented the lookahead for linefeeds, though it would have been
straightforward to extend this... Come on, terminal guys, it wasn't _that_
hard to do!
+----------------+
! II CCCCCC ! Jim Cathey
! II SSSSCC ! ISC Systems Corp.
! II CC ! Spokane, WA
! IISSSS CC ! UUCP: ihnp4!tektronix!reed!iscuva!jimc
! II CCCCCC ! (509)927-5757
+----------------+
"With flow control like this, who is needing enemas?"
Eric Green
> Xref: killer comp.sources.d:841 comp.terminals:317 comp.emacs:1111
> 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.
AMEN!
A friend of mine wrote a TVI910 emulator for the COMMODORE 64! He used an 8k
bit-map hi res screen to emulate 80 columns (via a 4-bit-wide character set)
on a machine with only a 40 column screen. Now, it takes about half a second
for a lowly 6502 to scroll an 8k area of memory. Everything else is just as
slow, too. So you'd expect some real bad flow control when going at 1200 baud.
Yet I never encountered any problems with Emacs, after he wrote in one simple
addition to the program: AN INPUT BUFFER. The RS232 port on a C-64 is already
interrupt driven, he just dedicated 4K of RAM to a buffer. So Emacs could
re-draw the entire screen and more, and I wouldn't lose a single character.
Of course, listing long directories or "cat"'ing things barfled things up, but
the "more" command solved that problem.... "more" could spit its stuff out at
full speed, and it'd be just filling up the buffer....
Of course, this DID make flow control and interrupts a bit... problematic. I'd
hit a control-C, and about 10 seconds later, after the buffer emptied, would I
see the "^C %".
Eric Green
{ihnp4,cbosgd}!killer!elg e...@usl.CSNET
PS: Last I heard, he'd sold his latest Amiga program to PP&S for a hefty sum,
I guess the cream really DOES rise to the top!
Roy Smith
The last terminal I saw which could keep up with a steady 19.2
kbaud was the good old ADM-5. True, it didn't have all the fancy ansi
escape sequences, but I think you could simulate a reverse-scroll by
redrawing the whole screen at 19.2 faster than you could do it for real on
a VT-10[012] at 4800 if you didn't mind the CPU load. Maybe the RISC
people have the right idea. The ADM-5 also had the advantage that you
could usually fix it with nothing more than a print set, a 'scope, and a
stock of generic 74XX chips.
Seriously, I don't see any reason why terminals can't have both
fancy ansi escapes and be able to handle a steady 9600. A faster clock for
the micro, some hardware assist for scrolling, and a nice buffer should be
all you need. Maybe somebody could just burn the ADM-5 logic into a gate
array :-).
--
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016
Barry Shein
From Bill Stewart
>There are two real issues here - how fast can a terminal go with flow control
>enabled, and how fast can it go with flow control disabled. While it's nice to
>have a terminal that can keep up with 19200 without flow control (i.e.
>continuous text display), that's approximately 19200 words per minute, and
>neither you nor I nor Evelyn Wood's mother can read that fast over sustained
>periods. The reasons you'd want a terminal to go that fast without flow
>control are either that you use a braindamaged computer which can't handle it,
>or that you're using EMACS, and flow control ^S puts you into search mode.
>(The solution there is to fix the software.)
I doubt you could read a terminal running at 1200b for a sustained
period of time, yet I'd bet you prefer a higher speed. Why?
Because there's more going on, many screenfuls contain little
information but need to put up the entire screen because it's too hard
to predict what you need in advance and/or the rest of the image
creates a context. Two good examples of this are Emacs' incremental
search where often a squinty-eyed view of the screen tells you you
need another screenful (eg. looking for a function definition, you
don't need to even focus your eyes to see you haven't found it yet in
most languages) and games (ok, maybe not the most serious application,
but I think it's an example of something.)
Also, given the higher speed updates more visual information can be
built into applications rather than trying to minimize screen update
(such as drawing boxes around relevant items, using screen attributes
like bold and blinking etc.) Any of this gets painful at even the
faster screen speeds real quick.
Here's to human factors engineering. It's subtle.
-Barry Shein, Boston University
Scott Alexander
>
> The last terminal I saw which could keep up with a steady 19.2
>kbaud was the good old ADM-5. True, it didn't have all the fancy ansi
>escape sequences, but I think you could simulate a reverse-scroll by
>--
>Roy Smith, {allegra,cmcl2,philabs}!phri!roy
>System Administrator, Public Health Research Institute
>455 First Avenue, New York, NY 10016
Back at Rice, we had a passel of wyse-75s. Near as we could tell,
they kept up nicely at 19.2kb. Now, I was never certain that the DEC
terminal multiplexers and VMS and Unix were sending out that 19.2 w/o
piles of space between the characters, but my emacs never complained
about ^s/^q problems. It is even compatible with the vt100 (though
not the vt10x for just about an value of x.)
Scott Alexander
sa...@linc.cis.upenn.edu
Kenneth Ng
[edited discussion on 'need' for flow control in terminals and how fast
a human can read]
> I doubt you could read a terminal running at 1200b for a sustained
> period of time, yet I'd bet you prefer a higher speed. Why?
>
> search where often a squinty-eyed view of the screen tells you you
> need another screenful (eg. looking for a function definition, you
> don't need to even focus your eyes to see you haven't found it yet in
> most languages) and games (ok, maybe not the most serious application,
> but I think it's an example of something.)
Here's an actual example: a few years ago I worked a part time job
in collge typesetting for a print shop. Sometimes I'd would have to
look over someone else's work on the computer and correct spelling.
When I read the file off of disk, the file displayed on the screen at
about 4800-9600 baud. I was able to catch most of the spelling errors
while it was displayed at that rate. My employer thought that I was joking
around when I did this, but when I went exactly to the mistakes and
corrected them, she thought I had pretty good reading.
My personal view on the terminal update speed, computer speed, compiler
speed, etc. is simple: *FASTER* *BETTER* *STRONGER*! We have the
techology (to quote the Six Million Dollar Man).
... This signature was put in in a way to bypass the
... bogus artificial line limit on the .signature file.
... Also, by its length it adds fodder to help avoid having
... my followups being bounced due to the restriction on
... followup articles.
Kenneth Ng: Post office: NJIT - CCCC, Newark New Jersey 07102
uucp !ihnp4!allegra!bellcore!argus!ken *** NOT k...@bellcore.uucp ***
bitnet(prefered) k...@orion.bitnet