C70:editor-people (06/19/82)
>From POURNE@MIT-MC Sat Jun 19 01:59:29 1982
Whoa? You know more than me. Godbout uses DTR as a means of
connecting terminals to the CPU; it works good, and the Xon Xoff
stuff is much harder to implement at fast baud rates; or so my
engineers tell me.
I am using my Televideo 950 rather than a Dec VT-100 because the
Vt100 has only Xon Xoff, and my CBIOS really wants DTR (with the
Godbout System Support Board). Is there something wrong with
this that I don't know about?
My engineeers are writing interrupt driven protocols to use the
vt-100 with the computer at 19000 baud. Shouldn't they be? They
claim the Xon Xoff will not be satisfactory. I don't know why.
Can you inform me?C70:editor-people (06/19/82)
>From Frankston.SoftArts@MIT-MULTICS Sat Jun 19 02:39:12 1982
editor-people at SU-SCORE, Goldberg at RUTGERS
Remailed-date: 19 Jun 1982 0001-PDT
Remailed-from: J.Q. Johnson <Admin.JQJ at SU-SCORE>
Remailed-to: Editor People: ;
{More discussing Xon/Xoff issues, skip this if you are not interested}
There is a big difference between something that just happens to work
in one case for random reasons and some that works. A propeller
airplane is a lousy means of getting to the moon.
DTR might just happen to work between two pieces of hardware. On the
other hand it is more likely to hangup your phone. At least ^S/^Q
can be passed over a communication line. I would guess that Xon/Xoff
is considered much harder to implement because you are speaking to
hardware people who seem to be unable to deal with things that are
not implemented solely in chips. All it takes is an interrupt
handler that is able to operate within the skid time of your
terminal. For a VT100 that is about 16 character times which as
19200 is 1/19200*10*16 seconds which 8.32 milliseconds. To be
conservative, let's assume 4 milliseconds. That is a very long
period of time. A real VT100 is closer to operating at 4800 baud
anyway so that cranking it up to 19200 doesn't really help you.
Probably 9600 is better for it.
This is not to say that Xon/Xoff is a good protocol. It is a rather
poor one, but it is available on many terminals. If we were redoing
the world, then there would be a transport level that deals with such
matters and does it out of band. Such mechanisms to exist, but are
not in the domain of this discussion.C70:editor-people (06/20/82)
>From POURNE@MIT-MC Sun Jun 20 01:09:53 1982
Excuse me, I thought that "ideal" specs were PRECISELY the domain of
this discussion. I freely admit I know damned little about hardware,
and probably not as much as I think I do about software; what I do
have is (1) a hell of a lot of experience USING these machines to
create both text and programs--I probably have done as much pounding
on keyboards as anyone you know, certainly as much as most students
you know--and (2) the ability to explain things to people once I
understand them.
I also know many of the movers and shakers in the micro part
of the computer industry, and I would LOVE to have "ideal" stuff to
discuss with them; who knows, it might end up being built by Godbout
or Morrow.
My apologies for my ignorance of the limits of DTR as a means
of communicating bettween terminal and computer. Some people who know
far more than I do about it seem to use it with success, and even to
believe that the other protocols are out-dated. Obviously that view
is not universal. On the other hand, the view that DTR is somehow
more advanced and preferable to Xon Xoff etc is not, I think,
contemptible.
I would be very interested in knowing what is the "best" way
of accomplishing this task, although perhaps it is not relevent to
editor-people. Perhaps, though, it is: since we are, I thought,
trying to work on future systems incorporating what all of us would
like to have...
[Editor's note: personally, I don't think that further XON/XOFF discussion
is appropriate to editor-people at this time; we seem to have covered most
of the important issues. Perhaps the discussion should move to some other
digest as it moves into the realm of hardware interface and out of human
interface. /JQJ ]C70:editor-people (06/24/82)
>From DPR@MIT-XX Wed Jun 23 17:32:18 1982
[ Editor's note: The following very complete message on flow control is, I
hope, the last that will appear in Editor-People (unless someone has
novel comments that specifically address the relation of flow control
and editing). Let's move the discussion to Human-Nets. /jq ]
Although I'm not a regular contributor to "editor-people", Bob Frankston
forwarded some comments that Pournelle made about the appropriate flow
control mechanisms for terminals.
As one of the long-time people in the business (not as long as Frankston,
who has been programming since 1963 -- I've been coding since '67), I am
amazed that the "movers and shakers" Jerry refers to know so little about
why the computing world is the way it is, and why we have gone past the
limits of the old technologies that led to the old design choices. In
particular, the use of the control key as an extra shift key goes back to
the widespread use of model 33 TTY's in the 60's which had an extra set of
non-printing chars that could be used when such terminals were hardwired
to computers (the 33 and old systems rarely utilized those chars).
Although modern keyboards are capable of generating all manner of
interesting code sequences, we still see the remnants of those poor
excuses for terminals in today's video editors!!! Surely this is a case
of unnecessary and bass-ackward backward compatibility.
The issues are not that complex, but are deeper than just the concern that
^S steals a useful keyboard character out of the character set. If you
will bear with a detailed explanation, I hope you will see that there is a
technical issue involved in doing it right that needs some fixing by the
terminal manufacturers, and some standardization in the industry to make
it fly. Unfortunately, more chaos (such as the suggestion that DTR be
used in a way that most computer manufacturers and most terminal
manufacturers sensibly don't support) is not helpful to anyone.
Both DTR and XON/XOFF (^S/^Q) flow control approaches are flwed in a
fundamental way -- they don't work well if the source of data is remote
and has significant delay. As communications speeds migrate from the 75
bits/sec that these mechanisms were designed for towards higher speeds and
with networks or front-ends that buffer characters on their way to the
receiver, these ideas are obsolescent or obsolete.
The basic problem is simple: both are based on negative-acknowledgment
("stop now! I can't take it any more") interactions, rather than
positive-acknowledgment interactions ("give me 20 more characters ...
thanks, now I'm ready for the next batch"). In general, positive
acknowledgment approaches are more robust than ones based on negative
acks, since the delay on receiver-to-sender messages does not affect
reliability.
The ideal flow control protocol for terminals is thus one that has the
receiver signalling when it is ready for more chars to be sent. To
enhance performance by keeping those bits flowing, the receiver shoudl
"double-buffer"-- that is, he should divide his buffer space in half, and
send "give me N more characters," where N is the half-buffer size,
whenever the receiver reaches the state where N of the buffer elements are
free. Unless the response latency on the path from rcvr-sndr-rcvr exceeds
the transmission time for N chars, there will be no pauses due to the flow
control (of course if the rcvr is slower than the sender, the sender will
pause.
Now for the buggy flow-control mechanisms:
DTR ON/OFF - is a gross violation of the protocol standard for RS-232C.
DTR off requires the modem to hang up. A better choice would be Request
to Send (RTS), which when off causes the sender to shut up eventually, and
seems to have been intended for this approximate purpose. The problem
here is that RTS or DTR are not defined to have any particular effect on
the sending PROGRAM. Most computers ignore these signals.
XON/XOFF - these at least sort of work over the communications links
between sender and receiver, and fit with the current ascii standards.
Note: ascii reserves the CONTROL characters for CONTROL functions on the
communications line. Terminals should use escape sequences, or
shift-out/shift-in (SO/SI) to get character set additions. I have no
objection to adding a shift key (call it CODE or even CONTROL) that
transmits a sequence like SO-typedchar-SI or ESC-|-typedchar when a char
is hit with the shift key set. The old terminets did that sort of (ESC
worked as a shift key), unfortunately the use of ESC as a raw char in
these editors makes the terminet choice inappropriate.
Both of the flow controls above don't work over long-distance lines too
well, since the round trip delay can be large fractions (1/4) of a second
when Bell starts using satellite links routinely (as she has threatened to
do in the near future). Nor do they work well over many networks.
Consider, for example, a pet project of mine, to get 4800 bps over dialup
lines by using a 4800 bps modem in half-duplex, fast turnaround mode. The
turnaround on these modems is about 50 msec (or about 25 chars), and would
cause 50-100 chars to be lost at the sender when trying to shut him up.
But with a positive ack flow control, all is copasetic, since the sender
will stop occasionally to wait for the positive ack.
By the way, the Xerox 1700 hardcopy printer does flow control in the way I
describe.
Peace --
Prof. David P. Reed