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.
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^Zjdia@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!
roy@phri.UUCP (Roy Smith) (06/22/87)
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 10016salex@linc.cis.upenn.edu (Scott Alexander) (06/23/87)
In article <2751@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: > > 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 salex@linc.cis.upenn.edu