Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!think!!rlk From: rlk@.COM (Robert Krawitz) Newsgroups: comp.sources.d,comp.terminals,comp.emacs Subject: Re: VT100's keeping up at high baud rates Message-ID: <5490@think.UUCP> Date: Wed, 17-Jun-87 09:26:05 EDT Article-I.D.: think.5490 Posted: Wed Jun 17 09:26:05 1987 Date-Received: Sun, 21-Jun-87 09:20:15 EDT Sender: news@think.UUCP Reply-To: rlk@THINK.COM Organization: Thinking Machines Corporation, Cambridge, MA Lines: 73 Xref: mnetor comp.sources.d:860 comp.terminals:316 comp.emacs:1174 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^Z