gore@nucsrl.UUCP (Jacob Gore) (11/25/86)
In one of the installation documentation files for GNU Emacs, Richard Stallman
expresses his displeasure (to put it mildly) with the way DEC's terminals use
control-S and control-Q (XON/XOFF) for flow control. He says its a
"brain-damaged" design.
Could somebody tell me why that is the case? If that is the case? What would
be a better synchronization method? The only decent method I can think of
would use hardware handshaking...
Jacob Gore
Northwestern University, Computer Science Research Lab
{ihnp4,chinet}!nucsrl!gore
P.S. Sorry for posting this to two groups (comp.terminals and comp.emacs),
but Notes can't cross-post yet.karl@osu-eddie.UUCP (11/27/86)
gore@nucsrl.UUCP writes: >In one of the installation documentation files for GNU Emacs, Richard Stallman >expresses his displeasure (to put it mildly) with the way DEC's terminals use >control-S and control-Q (XON/XOFF) for flow control. He says its a >"brain-damaged" design. > >Could somebody tell me why that is the case? If that is the case? What would >be a better synchronization method? The only decent method I can think of >would use hardware handshaking... That's what CTS & RTS (clear-to-send and request-to-send) are for: hardware handshaking. And if UNIX tty drivers and related hardware were set up to do it properly, that would be the way to go. Otherwise, the solutions are either to make a terminal for which padding can be sufficiently easily specified, so that you basically trust the terminal not to get behind and screw up; or just make a terminal whose firmware is faster than its fastest data rate. (Don't laugh, it's not that difficult. It's a poor commentary on DEC et al that they can't do so themselves.) As it is, making ^S/^Q into flow-control chars forces them into being an awful special case. If people aren't to type ^S or ^Q, why is ^U acceptable? Or ^Z? Or ^C? Or any of those other characters people have learned to love on their ASCII terminals? While I sometimes disagree with the (perhaps caustic) view taken by Richard toward ^S/^Q, I have to agree with the basic position: it's a bad design. -- Karl
ddb@viper.UUCP (Bennet) (11/29/86)
I don't know what RMS considers brain-damaged about ^S / ^Q flow control (other than the obvious problem that it uses up two keys that have obvious mnemonics in a text editor). I, however, think that a "positive" flow control scheme will in general be more reliable than a negative one like xon/xoff. The problem with a negative scheme is that at every stage where the things are handled, there are some critical response requirements; if you don't stop sending fast enough after you receive your ^S, you will overrun the buffer in your receiver. A positive system, on the other hand, works by saying "You may now send me up to 15 characters". You do so. Nobody has to jump around trying to avoid timing windows. DEC uses something like this in their LAT protocol on Ethernet. There's also some sort of a variant on this in some older microcomputer terminal protocols, if I remember correctly. -- David Dyer-Bennet
d2c-mt@luth2.UUCP (11/30/86)
In article <3910001@nucsrl.UUCP> gore@nucsrl.UUCP writes: >In one of the installation documentation files for GNU Emacs, Richard Stallman >expresses his displeasure (to put it mildly) with the way DEC's terminals use >control-S and control-Q (XON/XOFF) for flow control. He says its a >"brain-damaged" design. > >Could somebody tell me why that is the case? We had this problem with our vt100-compatibles: Whenever the terminal couldn't catch up with the computer, like when deleting a large area of the text on the screen, it would report some errors and then start up again with the emacs saying: I-search: ^Q Now the terminals have a 2 kB buffer memory, so that's no problem any more. But, for a time, it was rather annoying. --------- mik2o -- ----------------------------------------------------------------------------- "World War III is imminent Mikko Tyolajarvi PROGNOSIS: Many megadeaths, no blame." ...!seismo!mcvax!enea!luth!d2c-mt -----------------------------------------------------------------------------
roy@phri.UUCP (Roy Smith) (12/01/86)
In article <388@viper.UUCP> ddb@viper.UUCP (David Dyer-Bennet) writes: > A positive system, on the other hand, works by saying "You may now send > me up to 15 characters". You do so. Nobody has to jump around trying > to avoid timing windows. Two problems with this. The first is that it adds extra overhead, and makes the protocol more complicated to boot. It can reasonably be argued that with 9600 baud lines it doesn't much matter if you burn a few extra characters per line of output. It can also be reasonably argued that with smart serial line controllers and smart terminals, most of this added complexity can be hidden from the user. The second problem is harder to get around. Let's say you tell me that it's OK to send 15 characters now. Does that mean 15 graphic (i.e. printable) characters, or can it include a "run confidence test" escape sequence which could take 5 minutes to complete? That may be an extreme example, but consider than even a simple NL/CR with smooth-scroll turned on may take a good fraction of a second. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016 "you can't spell deoxyribonucleic without unix!"
warren@ihwpt.UUCP (warren montgomery) (12/01/86)
Others have covered most of the problems with the ^S/^Q flow control scheme. I would like to add one more place where the implementers of this scheme made what I feel is a serious mistake: The protocol provides no escape mechanism to allow one end to tell the other that "this ^S is for real, not for flow control". All of the other special characters in unix can be escaped in order to pass through. If the same rules had been applied to ^S and ^Q, then a smart terminal could be programmed to generate \^S and \^Q on function keys or even on the keyboard in some cases, while using ^S/^Q for flow control elsewhere. The place this lack really shows up is in "cu", and similar unix-to-unix connection programs, which frequently wind up needing ^S/^Q flow control but provide no mechanism for passing ^S and ^Q through transparently. With most or all of the emacs implementations around you can work around the problem through special control character prefixes, remapping the keyboard, and similar mechanisms, but it still is the number one source of user trouble reports for me, because working around the trouble is tricky. -- Warren Montgomery, ihesa!warren
chris@mimsy.UUCP (Chris Torek) (12/01/86)
In article <2518@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >... [positive flow control] adds extra overhead, and makes the >protocol more complicated to boot. I agree with the first half of the argument, but not with the second half. Negative flow control is at least as hard to get right as positive in the presence of data link errors. (Most people ignore the link errors, wreaking havoc when it is least expected.) >It can reasonably be argued that with 9600 baud lines it doesn't much >matter if you burn a few extra characters per line of output. Most terminals cannot even stuff characters into their displays at 9600 baud (purely a personal observation), so since they are spending much of their time controlling flow, at that rate it would not matter how the control is implemented. At lower baud rates, however, negative flow control starts to look better, for it is rarely used, and when it is used, there is more time to respond. >... Let's say you tell me that it's OK to send 15 characters now. >Does that mean 15 graphic (i.e. printable) characters, or can it >include a "run confidence test" escape sequence which could take 5 >minutes to complete? Certainly. >That may be an extreme example, but consider than even a simple NL/CR >with smooth-scroll turned on may take a good fraction of a second. Modern terminals tend to have a FIFO chip in between the serial port and the code to interpret incoming characters. The size of the FIFO varies between 32 and 128 characters. (Other terminals, being computers, use interrupts and real RAM to store characters, and have 1K or more of FIFO, which is much better.) The terminal can look at the FIFO and see that there is room for 15 characters. That space is there to stay; indeed, it will increase as the terminal does more work. Both negative and positive flow controls have their uses. For direct, slow connections, negative is probably the better choice. For indirect (networked) or fast connections---4800 baud is `fast' to most terminals, though there is no real reason not to use, e.g., 38400 baud, except that most *computers* cannot use that bandwidth--- for these, positive flow control is really the only reliable alternative. But no matter which is used, flow control should always be transparent. Even ASCII provides a Data Link Escape! Alas, it is a bit late to begin using it. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) UUCP: seismo!mimsy!chris ARPA/CSNet: chris@mimsy.umd.edu
jr@CC5.BBN.COM (John Robinson) (12/01/86)
Karl Kleinpaste <cbatt!osu-eddie!karl@ucbvax.berkeley.edu> writes: >> That's what CTS & RTS (clear-to-send and request-to-send) are for: >> hardware handshaking. And if UNIX tty drivers and related hardware >> were set up to do it properly, that would be the way to go. >> Otherwise, the solutions are either to make a terminal for which >> padding can be sufficiently easily specified, so that you basically >> trust the terminal not to get behind and screw up; or just make a >> terminal whose firmware is faster than its fastest data rate. (Don't >> laugh, it's not that difficult. It's a poor commentary on DEC et al >> that they can't do so themselves.) True enough. We made this work in BBN's Unix machines. It was neat to run a terminal at 19200 with no padding in RAW mode and have it drop nothing, even though the terminal was fairly fancy and unable to keep up with XOF/XON. (The Unix machine of course could :-). The question of what to consider "control" characters has no clear answer, as the other postings on this topic have pointed out. ASCII does single out the control characters (\000 through \037) and RUBOUT (\177) for special treatment, but it also allows for "transparent" operation, where no characters are special. RMS clearly prefers the latter, and for some applications, such as binary file transfer with trustworthy lines, it is a big win over other techniques that avoid the control characters. The trouble with RTS/CTS (or other modem control signal use) is that it is hard to pass them through modems, especially in full-duplex operation, and you can't use them with any network that provides "transparent" terminal connections. "Network" here must be general enough to include such things as fancy rate-adaptive modems like Microcoms or (I think) Trailblazers. So what to do? One approach, advocated in this list, is to accept the non-transparency of XOF/XON and get by with other characters or sequences (ie, ^\ or ESC-S), using the unused control characters. While this risks the possibility that some other terminal/modem/network will preempt another control character someday, this is probably unlikely to happen now that so much async ASCII stuff is out there. (I once was exposed to a terminal that displayed only upper case and used the lower case characters for terminal control. Ouch!) The other approach is to define more elaborate framing rules, which is what synchronous protocols do (like X.25, Binary Synchronous or HDLC). Although these tend to be associated with synchronous transmission, in fact binary synchronous and other protocols (eg DDCMP) are perfectly happy to run over async lines. The "frame" of async ASCII is the (typically 8) data bits between the "start" and "stop" framing bits. To get more elaborate, you have to put more bits in. The typical way to do this is to build multi-character frames using some of the ASCII characters as delimiters, and then devise ways to send the framing characters when they appear in the data stream. Now the bits within the frame can have uses other than data, like sequence numbering, acknowledgment, checksum, etc. and you can build up a pretty sophisticated protocol if you wish. In particular, positive-acknowledgment protocols, advocated in another message on this topic, are possible, with windowed flow control, multiple logical channels, and so forth. The US ANSI committee X3S3.4, of which I am a member, has proposed an addition to the ISO HDLC standard that would add just such a framing technique for sending HDLC-family protocols over asynchronous hardware. This would permit software on PCs, for example, to use HDLC, X.25, or SDLC protocols with only asynch hardware and modems. It has been introduced to ISO; we'll see where it goes. /jr ps. posted only to unix-emacs/comp.emacs. If someone would like to cross-post to the other list mentioned, please feel free.
rbj@ICST-CMR.ARPA (Root Boy Jim) (12/01/86)
> gore@nucsrl.UUCP writes: > >In one of the installation documentation files for GNU Emacs, Richard Stallman > >expresses his displeasure (to put it mildly) with the way DEC's terminals use > >control-S and control-Q (XON/XOFF) for flow control. He says its a > >"brain-damaged" design. > > > >Could somebody tell me why that is the case? If that is the case? What would > >be a better synchronization method? The only decent method I can think of > >would use hardware handshaking... > That's what CTS & RTS (clear-to-send and request-to-send) are for: > hardware handshaking. And if UNIX tty drivers and related hardware > were set up to do it properly, that would be the way to go. YOU got it right, Karl, but just as many people would use DTR & DSR, or some other random signal. In any case, it only solves half the problem, as I will elaborate below. > Otherwise, the solutions are either to make a terminal for which > padding can be sufficiently easily specified, so that you basically > trust the terminal not to get behind and screw up; Padding is an ancient concept, one that no one should have to deal with. It's computationally intensive, confusing at best, and frequently wrong. > or just make a > terminal whose firmware is faster than its fastest data rate. (Don't > laugh, it's not that difficult. It's a poor commentary on DEC et al > that they can't do so themselves.) Or that they chose another method. It's easier to stick a kilobyte in a terminal and send ^Q/^S when certain limits are reached rather than worry about miniscule timing intervals. In short, it's dynamic and adaptive rather than static and rigid. Besides, it only solves *part* of the problem. If I need to stop a long output (e.g. `ls -l /etc), there is no `drop CTS' key. All I can do is type a character, or drop DTR (by turning of my terminal), not much of a solution. Padding doesn't solve that problem. Okay, so I could pipe it thru a pager (but I didn't when I started that monster grep and I changed my mind), or I could even put the pager in the tty handler (but that usurps another character or two and requires) modes to turn the feature on/off. > As it is, making ^S/^Q into flow-control chars forces them into being > an awful special case. If people aren't to type ^S or ^Q, why is ^U > acceptable? Or ^Z? Or ^C? Or any of those other characters people > have learned to love on their ASCII terminals? Well, strictly speaking, you can't. Perhaps you might look at the ANSI spec for ASCII (X3.64 or something). It describes several classes of control characters (in no particular order and with no particular accuracy, it's been awhile since I looked at it): [1] Format Effectors -- White space to UNIX types. These things don't print anything, but make printers and things go bump in the night. They consist of BS, HT, LF, VT, FF, and CR. Possibly BEL. [2] Communications -- Protocol stuff. SOH, STX, ETX, EOT, ACK, DLE, NAK, SYN, ETB, CAN, EM, SUB. [3] Character Set Extension -- ESC, SO, SI. Alternate character sets. [4] Data Formatting -- FS, RS, GS, US. Interestingly enuf, SPC can be thought of as WS, a `word separator'. [5] Device control -- DC[1-4]. Once upon a time turned ASR-33 paper tape readers/punches on/off. XON & XOFF in more modern times. [6] Whatever I missed. NUL and DEL are somewhat special, possibly they go in the communications category, but they often have media problems (magtape) or special significance (paper tape). In any case, controls characters are reserved *for the implementation* (all the system stuff) while the graphics are reserved *for the users*. The fact that you see *any* control characters at all is gravy. Some systems, like VMesS, filter them `for' you. > While I sometimes disagree with the (perhaps caustic) view taken by > Richard toward ^S/^Q, I have to agree with the basic position: it's a > bad design. At least, to his credit, he hacked in `set-input-mode'. There isn't much `protocol' to async ascii, but flow control seems to be universally required. Most people use the ^Q/^S convention. With unknown gateways, concentrators, and translation boxes between here and there, it gets weirder than just plain padding. M-x yours-truly RET > -- > Karl (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> I wish I was on a Cincinnati street corner holding a clean dog!
rwells@PROPHET.BBN.COM (12/02/86)
There is another approach to dealing with ^S/^Q that is worth considering. Your terminal or terminal emulator could have a mode in which it translates keyboard entry of Control-S and Control-Q into something else - either multi-character escape sequences or other control characters. You then initialize emacs to recognize these translated sequences as equivalent to real ^S/^Q, something those of us plagued with flow control problems already have to do anyway. This would allow you to type the nice mnemonic keystrokes while staying out of the way of flow control. There are probably existing ibmpc terminal emulator programs with keystroke macros powerful enough to do this kind of keyboard translation, if you are having flow control problems when using a pc as a terminal. -Robert
gnu@hoptoad.uucp (John Gilmore) (12/02/86)
In article <8612020023.AA05566@ucbvax.Berkeley.EDU>, rwells@PROPHET.BBN.COM writes: > Your terminal or terminal emulator could have a mode in > which it translates keyboard entry of Control-S and Control-Q into > something else - either multi-character escape sequences or other > control characters. You then initialize emacs to recognize these > translated sequences as equivalent to real ^S/^Q... Therein lies a problem. Only a few of the Emacs dependencies on ^S and ^Q are in the nice keymaps; the rest are hardwired into Lisp or MockLisp code. E.g. in incremental search in Gosmacs, the mlisp macro reads the keyboard, checks for ^R or ^S (to change the direction of search) and then does the search for that character. Changing ^S to M-S in the keymaps won't make M-S work properly inside incr-search. Quote characters like ^Q tend to be embedded even worse. So far nobody seems to have define a way to ask "Does this character map to the function 'incr-search'?". Even that would not be powerful enough to cope with a multi-character sequence for ^S, or for environments where ^S is bound to a function that does some work and *then* calls incr-search. -- John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgilmore@lll-crg.arpa Call +1 800 854 7179 or +1 714 540 9870 and order X3.159-198x (ANSI C) for $65. Then spend two weeks reading it and weeping. THEN send in formal comments!
jon@amc.UUCP (Jon Mandrell) (12/03/86)
RTS and CTS are *not* used for flow control at the application level. A DTE device sets RTS when it wishes to send something, which tells the DCE device (a modem) that it should do whatever is necessary to be ready to get some data. Then the modem raises CTS indicating that the device may send data. RS-232C is so misused by so many devices. There is a whole set of secondary channel signals defined for the DB-25 series of connectors which can be usurped, without screwing up current modem connections. I agree ^S/^Q was not a good choice, but the CTS/RTS or DSR/DTR pair are no better. -- Jon Mandrell (ihnp4!uw-beaver!tikal!amc!jon) Applied Microsystems Corp. "flames >& /dev/null" - me
ddb@viper.UUCP (David Dyer_Bennet) (12/04/86)
In article <2518@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: > Two problems with this. > The second problem is harder to get around. Let's say you tell me >that it's OK to send 15 characters now. Does that mean 15 graphic (i.e. >printable) characters, or can it include a "run confidence test" escape >sequence which could take 5 minutes to complete? That may be an extreme >example, but consider than even a simple NL/CR with smooth-scroll turned on >may take a good fraction of a second. >-- >Roy Smith, {allegra,cmcl2,philabs}!phri!roy It means specifically 15 (for example) BYTES OVER THE LINK. The size is tied to the ways things are buffered by the system giving permission. Even if those 15 chars include a "run confidence test" (not by any means impossible in the terminal environment I have in mind), since I had 15 chars of buffer space available when I gave you that permission, I am guaranteed of being able to handle the 15 chars you send, whatever they are. Regardless of screen representation or processing time required for them. The processing time issue is pretty much irrelevant, as far as I can see. The sender will wait forever for the receiver to give permission for more characters (thus introducing its own problems, if strictly interpreted...)