stevesu@copper.UUCP (06/13/87)
> - Some (all?) PC/clones cannot keep up with speeds > 4800 baud in the VT100 > - terminal emulator > > It sounds as if you're suggesting that any AT&T terminal will keep up at > speeds greater than 4800 baud! I have news for you: not all of them do. 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. Steve Summit stevesu@copper.tek.com
jpn@teddy.UUCP (06/15/87)
>> - 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 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?
sl@van-bc.UUCP (Stuart Lynne) (06/16/87)
In article <4101@teddy.UUCP> jpn@teddy.UUCP (John P. Nelson) writes: >>> - 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
bandy@amdcad.AMD.COM (Andy Beals) (06/16/87)
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
jpn@teddy.UUCP (06/17/87)
>>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.
wcs@ho95e.UUCP (06/17/87)
In article <1119@copper.TEK.COM> stevesu@copper.TEK.COM (Steve Summit) writes: >> - Some (all?) PC/clones cannot keep up with speeds > 4800 baud in the VT100 >> - terminal emulator >> >> It sounds as if you're suggesting that any AT&T terminal will keep up at >> 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
mkhaw@teknowledge-vaxc.UUCP (06/17/87)
In article <1490@ho95e.ATT.COM> wcs@ho95e.UUCP (46133-Bill.Stewart,2G218,x0705,) writes: >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: mkhaw@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
rlk@.COM (Robert Krawitz) (06/17/87)
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^Zjpn@teddy.UUCP (John P. Nelson) (06/17/87)
> 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. 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
jdia@osiris.UUCP (06/17/87)
Our TeleVideo 9220's (vt200 compatible) keep up at 19200 with flow control
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!walton@tybalt.caltech.edu (Steve Walton) (06/17/87)
In article <5490@think.UUCP> rlk@THINK.COM writes: >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 walton@tybalt.caltech.edu AMETEK Computer Research Division, ametek!walton@csvax.caltech.edu "Long signatures are definitely frowned upon"--USENET posting rules
jerry@oliveb.UUCP (06/17/87)
In article <5490@think.UUCP> rlk@THINK.COM writes: >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 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.
jimc@iscuva.UUCP (06/18/87)
In article <17160@amdcad.AMD.COM> bandy@amdcad.UUCP (Andy Beals) writes: >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?"
elg@killer.UUCP (Eric Green) (06/20/87)
in article <5490@think.UUCP>, rlk@.COM (Robert Krawitz) says: > 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 elg@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!
bzs@bu-cs.BU.EDU (Barry Shein) (06/23/87)
Posting-Front-End: GNU Emacs 18.41.4 of Mon Mar 23 1987 on bu-cs (berkeley-unix) 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
ken@argus.UUCP (Kenneth Ng) (06/30/87)
In article <8959@bu-cs.BU.EDU>, bzs@bu-cs.BU.EDU (Barry Shein) writes: [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? > > 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.) > -Barry Shein, Boston University 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 ken@bellcore.uucp *** bitnet(prefered) ken@orion.bitnet