chris@mimsy.UUCP (06/18/87)
In article <5988@brl-smoke.ARPA> gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: >Railing against the use of DC3 and DC1 for flow control by some terminals >is pointless -- they need to throttle incoming data, especially at high >bit rates and when performing complex actions such as line insertion.... They do indeed, but this is not all. I find it amusing, and somewhat sad, that all of this could have been avoided quite simply. There are four independent flow control actions: stop because the terminal's input buffer is full; restart because the terminal's input buffer is empty; stop because the user requested it; restart because the user requested it. Too few terminals distinguish between their own stops and user-requested stops. (Ann Arbor Ambassadors get this right. This is not an exhaustive list: that there are others I do not doubt.) These actions translate into two terminal-to-host requests: stop, and continue. These requests should be distinguishable from all input events. Alas, they are not. Perhaps what we, as users of terminals, should do is to adopt a new standard that may be implemented as an option in new terminal firmware. It would then be a Small Matter Of Programming to fix host terminal software also to implement this standard, and terminals that conform to the standard would have no trouble with flow control. (I believe such standards exist, but are not being used because they are, well, not *standard* enough. This is a political problem and one I cannot solve.) The immediate problem is to distinguish between user input and flow control sequences. In the simplest case this can be done with a form of byte stuffing: one character is defined as an `escape', and control-S can be represented as escape-s, control-Q as escape-q, and escape as escape-e. (Any three value suffice, but if we admit the possibility of transmission errors, some triples seem better than others.) More complex solutions include positive flow control and perhaps error detection and correction. In the end, we may wind up with something like TCP/IP built into the terminals themselves. For now, though, I shall muddle along with half- solutions and a sad smile. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris
drw@cullvax.UUCP (Dale Worley) (06/18/87)
(Note: RLK, your messages start with: From: rlk@.COM (Robert Krawitz), which is probably wrong.) Well, it's all well and good to talk about buffering as a way to reduce flow control, but I can't see any way to get the guaranteed-no-flow-control rate any better than the slowest operation the terminal supports. For example, if it takes 18ms to scroll, and the computer sends 10^6 ^J's, if you permit them to be sent much faster than one character per 18ms, you're going to have to buffer 1 MB of data. Ugh! Can you imagine how long it will take to get ^C to stop output? Now, if you can load-shed, say by performing a several-line scroll in the same time as a one-line scroll (bit-map displays are like this), then you can effectively just keep an up-to-date screen image in memory and update the real screen as time permits. Ultimately, ^S/^Q flow control is a quite reasonable concept if (1) the host software is assumed to not understand screen sizes, and so when you 'cat foo', you want to be able to stop the output and examine it (VT100 'smooth scroll' is a variant of this), and (2) there is no reliable 'extra' data path available. It's only recently when people have started using Emacs as a total user environment that (1) has been avoided in a significant fraction of common usage. No one uses a glass tty at 9600 baud! Dale -- Dale Worley Cullinet Software ARPA: cullvax!drw@eddie.mit.edu UUCP: ...!seismo!harvard!mit-eddie!cullvax!drw "President Nixon has just lowered the speed of light to 55 mph. At what speed can 2 colliding VW's of mass m = (number) produce a 3rd VW?"
reingold@uiucdcsp.cs.uiuc.edu (01/12/88)
This question has, no doubt, been answered here in the past, but I didn't
see the answer:
What does one do when flow control cannot be disabled?
Specifically, is there a way to salvage ^S/^Q?
In my case, I am accessing a computer over a Sytek net.chuck@mitlns.mit.edu (11/18/90)
-Message-Text-Follows- I've read RMS's notes on control-s/q flow control and I'm curious about it. I don't work on Unix machines, and I wonder how they handle flow control. Somewhere I got the impression that they did it by setting up timings of operations and sending out enough null codes after each command to ensure that the terminal has time to complete the operation before starting the next (padding). If this is true I don't see how RMS can reasonably claim that it is better than Xon/Xoff processing. This is not the same as saying that characters other than Q and S should of been used which may be a valid point if you have been using them for something else. (I don't like reprogramming my fingers either). Padding seems to be a miserable solution. A computer and serial driver are wasting time sending lots of nothing. And it can't reasonbly handle variable speed transmission, such as data compressing modems or internet. Most people like having there modems used for sending useful information, since thats one place where time=$. Also the computer requires lots of data for every terminal, which is a system maintenence burden. Someone care to set me straight? Is that really the typical way flow control is handled on Unix systems? Should I keep search bound to control s or should I change it? While I'm all for configurable editors I also think a standard interface is a very valuable thing. Chuck@mitlns.mit.edu
fin@norge.unet.umn.edu (Craig A. Finseth) (11/20/90)
In article <1990Nov17.203241.16722@athena.mit.edu> chuck@mitlns.mit.edu writes: > [Asking about padding vs. XON/XOFF flow control] > > If this is true I don't see how RMS can reasonably claim that >it is better than Xon/Xoff processing. It is better because (1) it doesn't take 2 of the 33 (yes, 33) available control characters and (2) it is completely out of band, and hence doesn't interfere with applications that need all 256 characters (e.g., xmodem). > Padding seems to be a miserable solution. A computer and >serial driver are wasting time sending lots of nothing. And Actually, it is quite reasonable. Any computer whose performance you care about will be using DMA and hence no CPU time is wasted. >it can't reasonbly handle variable speed transmission, such >as data compressing modems or internet. Most people like having there Actually, modem compression is irrelevant as it is only the speed of the final link to the display that is relevant. Network connections are a problem, though. >modems used for sending useful information, since thats one place >where time=$. Also the computer requires lots of data for every terminal, >which is a system maintenence burden. As it turns out, this is a wash. You will spend the time sending NULs or waiting for an XON, but you will spend the same time nonetheless. I don't understand the "system maintenance burden." These devices don't wear out by sending data. > Someone care to set me straight? Is that really the typical way >flow control is handled on Unix systems? Should I keep search >bound to control s or should I change it? While I'm all for >configurable editors I also think a standard interface is a very >valuable thing. Unfortunately, XON/XOFF is more typical (:-(. Personally, I keep search on ^S and campaign against XON/XOFF at every opportunity. Craig A. Finseth fin@unet.umn.edu [CAF13] University Networking Services +1 612 624 3375 desk University of Minnesota +1 612 625 0006 problems 130 Lind Hall, 207 Church St SE +1 612 626 1002 FAX Minneapolis MN 55455-0134, U.S.A.
jbw@bucsf.bu.edu (Joe Wells) (12/01/90)
In article <1990Nov17.203241.16722@athena.mit.edu> chuck@mitlns.mit.edu writes:
I've read RMS's notes on control-s/q flow control and I'm curious
about it. I don't work on Unix machines, and I wonder how they handle
flow control. Somewhere I got the impression that they did it by
setting up timings of operations and sending out enough null codes
after each command to ensure that the terminal has time to complete
the operation before starting the next (padding).
If this is true I don't see how RMS can reasonably claim that
it is better than Xon/Xoff processing. This is not the same as
saying that characters other than Q and S should of been used
which may be a valid point if you have been using them for something
else.
The problem with XON/XOFF flow control is that it is in-band instead of
out-of-band. Sending NULs is also an in-band method of flow control. I
interpret RMS's statement as being opposed to in-band flow control.
In general, any out-of-band method is superior. However, out-of-band
methods are more complicated to set up, and more politically difficult to
put into place. For the RS232 protocol, the DTR and DSR lines are already
there. Unfortunately, these signals aren't currently propagated across
modem-to-modem connections, and thus can't always be used for flow
control.
--
Joe Wells <jbw@bu.edu>