Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 beta 4/12/84; site rlgvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!houxm!houxz!vax135!cornell!uw-beaver!tektronix!hplabs!hao!seismo!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.unix-wizards
Subject: Re:  VT100 and bagbiting (actually ASCII debate)
Message-ID: <2076@rlgvax.UUCP>
Date: Thu, 5-Jul-84 17:10:58 EDT
Article-I.D.: rlgvax.2076
Posted: Thu Jul  5 17:10:58 1984
Date-Received: Sat, 7-Jul-84 07:09:38 EDT
References: <1321@sri-arpa.UUCP> <1990@utcsstat.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 57

> Doug Gwyn's comments about the USG terminal driver allowing DC3/DC1
> flow control in "RAW" mode need rebutting.  RAW mode (at least in v7)
> means eight-bit, uninterpreted I/O, so asking for DC3/DC1 flow control
> makes no sense since it implies that characters are being interpreted
> and some (DC3 and DC1) are not passed through.

The secret here is that the USG terminal driver doesn't have a "RAW" mode.
It permits you to independently select:

	7-bit(+parity) vs. 8-bit characters
	stripping characters down to 7 bits
	DC3/DC1 flow control

so one can have an 8-bit data path on input and still have DC3/DC1 flow
control.

> My main objection to DC3/DC1 flow control is that it is a negative
> acknowledgement scheme and certain brain-damaged terminals such as the
> DEC VT100 contain insufficient buffering to allow them to operate at
> high speed, especially when using smooth-scroll (which is too slow in
> the VT100).  The problem is worse if the terminal driver attempts to
> use silo alarms rather than taking interrupts immediately upon receipt
> of incoming characters.

UNIX has problems with the VT100, but do the DEC operating systems?  One
difference between UNIX and the DEC RSX family OSes (including VMS) is that
UNIX services interrupts entirely at interrupt priority level, while the DEC
OSes do as little as possible at interrupt level and drop down to a lower
level (although still higher than normal program level) for most of their
processing.  If the disk driver, or terminal driver, or whatever driver
interrupt service routine takes a significant amount of time to finish, in
UNIX that means the DC3 may not be seen by the host until the other ISR
finishes, which may be too late; this is less likely to happen on other OSes.
The silo alarm level should be set adaptively, so that if little traffic
comes in it's set to zero so an interrupt occurs as soon as the character
comes in.  The V7 DH11 driver did this, but for some reason that stuff wasn't
in 4.xBSD.  It's trivial to put back - I did it here, but we still saw
problems at 19200 baud with VT100s.  Either the level wasn't getting set right,
or that wasn't the problem - we did some profiling and found the system spent
a fair bit of time at priority level "5" (I put "5" in quotes because on a
VAX, "spl5()" sets it to a level which isn't really 5.  The names of the "spl"
routines are historical dregs.), most of it in the disk driver ISR.

Yes, DC3/DC1 is a negative acknowledgment scheme - but a scheme requiring
positive acknowledgments wouldn't have been backwards-compatible with terminals
which didn't know about it.  DEC (and other OS implementors) probably chose it
for that reason; a terminal which didn't do flow control would still work, and
a terminal which did would work.  Furthermore, a user can also use ^S and ^Q to
control the flow of output from the terminal (remember, RT-11 doesn't even have
general multi-tasking, much less pipes, much less "pg" or "more").  Yes, the
VT100 has less buffering than it should - but if the computer can stop in time
(which it might do with other OSes), what's the problem?  Whether smooth
scroll is "too slow" is a matter of opinion; I prefer the C. Itoh CIT-101
double-speed scroll, but I can happily live with my VT100's smooth scroll.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy