chris.umcp-cs@UDel-Relay (12/25/82)
From: Chris Torek <chris.umcp-cs@UDel-Relay> Date: 22 Dec 82 22:29:17 EST (Wed) Now hold on a minute here. We are running Berkeley 4.1 Unix, have many Ann Arbors connected to DH/DMs, running at 19200 baud, and they *DO* need padding. Null padding works fine (though I'll admit I'd rather have an ioctl(fd,TIOCDELAY,millisec) call). I won't dispute the fact that those nulls go into the input buffer (and thus could possibly overrun it): it is true. In "monitor mode" you can see that they are stored. HOWEVER: they DO have effect. What happens if they are not used is that the buffer fills up with lots of escape sequences; the buffer fills up; *NOW* you must wait. But the buffer is full... what can you do? Now suppose that they ARE used: you get one escape sequence, it gets decoded, now the terminal goes off and does it (taking any arbitrary amount of time); meanwhile, you SEND NULLS. After the AAA finishes with the escape sequence it looks in its buffer, and races over the nulls, and NOW you are free to send the next escape sequence. IT DOESN'T MATTER THAT YOU OVERRAN THE BUFFER! If you are careful you can indeed get away with this. According to the timing information that you get with the AAA (what little there is), you need to give the AAA time that just isn't there at lower baud rates for such things as insert/delete line. (For the screen clear you theoretically have to wait over 5 seconds (I think). In actual use you need from 1/4 to 1 seconds (I think).) In any case the padding IS necessary >>>at 19200 baud.<<< I didn't try 9600 after removing the initial Emacs driver bugs . In the end I just rewrote the driver. Someone mentioned keeping the terminal out of true raw mode, so that the 'values>=0200' delay was usable (with an appropriate mod to the tty driver so you can get them there in the first place). While this would work on an AA, believe it or not, I've used a terminal where all those eight bits are necessary. It turns out that [possible bug in Emacs termcap driver here] if you put \201 in a termcap Emacs really sends the high bit, and that's what I ended up using. (The reason I said 'possible bug' is that some terminals might take NUL as a pad character but not \200, and you use \200 to get intra- sequence padding in termcap [yes, this is sometimes necessary!], so Emacs will send \200.) We had at one time a tty driver (for V6) that could still do output delays even in raw mode, by using character stuffing to fit the delay information into the output queue. I think this is a better solution than \2xx for delays, since it would be nice to be able to use 8 bits AND delay (say for some strange file transfer program to a micro, that knows how long the micro takes to write to its disk).
dmmartindale (12/27/82)
Now, come on. I have an Ambassador sitting in my office which runs at 19.2Kb connected to a VAX running 4.1BSD, and our termcap entry specifies NO PADDING for any function. The terminal has Auto XON/XOFF set and whenever its input buffer gets close to being full, it simply sends an XOFF to shut the VAX up for a while until it can catch up. If the terminal doesn't get too far behind, then no flow control occurs. The screen is always updated as fast as the terminal is able. If you use padding instead of flow control, if you provide worst-case padding then most of the time the terminal isn't getting commands as fast as it could be processing them. Also, if you are running your terminal over a network of some sort which supports flow control (e.g. Sytek localnet) the terminal will flow control the network if it's necessary and the network can flow control the VAX if necessary. This seems better than using up network bandwidth transmitting all that extra padding over the network. (how many characters constitute worst-case padding for a screen clear at 19.2K?) Finally, reading through a copy of the new Ambassador manual not long ago, I seem to remember that you could specify that rubouts were to be treated as a real pad character, i.e. thrown away as they come out of the UART instead of being put into the buffer. Dave Martindale
gwyn@Brl (12/31/82)
From: Doug Gwyn <gwyn@Brl> Date: 30 Dec 82 19:37:59-EST (Thu) I fully agree with what you say about flow control for your terminal. The same could be said about the VT100 and many other terminals. As near as I can tell, the problem arises because some people insist on their "right" to use ^Q and ^S as user-typed commands to screen editors, or because someone hasn't implemented XOFF/XON flow control correctly (I believe the original 7th Edition UNIX tty driver botched this, so that compatible drivers also don't work right).
obrien@Rand-Unix (12/31/82)
Date: Thursday, 30 Dec 1982 20:29-PST Unfortunately certain programs MUST run in raw mode (CBREAK won't do), and XON/XOFF doesn't work in raw mode. Well, it does on our system, if you set a local mode bit, but we hacked the kernel to do that.
MCLINDEN@Rutgers (02/28/83)
From: Sean McLinden <MCLINDEN@Rutgers> Date: 31 Dec 1982 1631-EST Not only do I insist on my "right" to use ^S and ^Q in whatever way I see fit, but I also would suggest that whoever decided that the XON/XOFF protocol should be implemented using the ASCII character set was off-base. The use of the ASCII characters should be under the complete control of the user. I don't expect my car to be signalling turns without my knowledge and I don't wish for my terminal to be sending characters in that fashion, either. The standard hardware I/O connector on most terminals and most of the asynchronous interfaces I know of (e.g. DZ-11), provide Request to send and Clear to send signal lines which would not interfere with the transmission of the user's signal. The problem is created when shortcuts are used, and the XON/XOFF protocol is a shortcut. Besides, ^S is a natural key to bind a search command to. As I recall, the standard EIA interface provides nine signal lines; how many are used, 6? -------
faunt (02/28/83)
Contrary to your statement, DZ11`s DO NOT support CTS and RTS. Nor do ABLE DH/DM`s, nor do DEC DH11`s without the DM11.
thomas (03/01/83)
Ah, but the Able DH/DM will take a CTS type signal on the RI(!) line. We've been using it here with great success. This is selectable per channel via a jumper, I believe. =Spencer
henry (03/03/83)
The flow-control-with-XON/XOFF issue has been beaten to death on at least one other mailing list in the past. The basic points that emerged were three: 1. The DC1 and DC3 characters used in XON/XOFF flow control are ASCII ***control*** characters. Said control characters were never intended for use by the user at all, much less to be under his "complete control". The folks who used DC1 and DC3 (also known as XON and XOFF) for flow control were entirely within their rights. Any software which assumes that control characters allocated to device or transmission-link control can be send and received as data characters is wrong. It is only an accident that many transmission links pass them intact. Note that there is no requirement that ^Q and ^S send DC1 and DC3 respectively; they could easily send escape sequences which *are* legitimate data and *would* be passed through intact. Complain to your terminal manufacturer. 2. RTS and CTS are not really intended for this job either. Nor are they workable for this purpose across networks. 3. In fact, *none* of the common flow-control protocols are practical for network use, because they all rely on "stop, I can't take any more" signals which don't work properly when transmission delays become substantial. Henry Spencer U of Toronto
dmmartindale (03/04/83)
I believe that the Request to Send and Clear to Send lines were provided for use with half-duplex modems - RTS told the modem to turn on its carrier and CTS indicated that the modem was stable enough for transmission of data to begin. Full-duplex modems may provide no useful information on these signals. In any case, they certainly aren't propagated to the modem on the other end of the line, and there are many terminals in the world connected to computers by modems. The only possible means of flow control under these circumstances is some form of "in-band" signalling, whether it be XON/XOFF or ENQ/ACK or acknowledgement of received data. Modem control leads are useful for controlling modems, but not for end-to-end things like flow control.