[comp.emacs] Flow control

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>