Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site rlgvax.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!rlgvax!guy From: guy@rlgvax.UUCP (Guy Harris) Newsgroups: net.unix-wizards,net.dcom Subject: Re: any harm in allowing only ctrl-Q to restart output? Message-ID: <323@rlgvax.UUCP> Date: Fri, 4-Jan-85 01:31:35 EST Article-I.D.: rlgvax.323 Posted: Fri Jan 4 01:31:35 1985 Date-Received: Sat, 5-Jan-85 03:01:36 EST References: <247@lsuc.UUCP> <104@redwood.UUCP> <319@rlgvax.UUCP> <6934@brl-tgr.ARPA> Organization: CCI Office Systems Group, Reston, VA Lines: 52 Xref: watmath net.unix-wizards:11349 net.dcom:762 > Whether interrupt should unstall output depends on whether one > views DC3/DC1 flow control as user-controlled or as hardware- > controlled. It is more important to get the hardware working > right, to avoid hung terminals... Bravo! (Although Bravo probably didn't have this problem, since if the CPU can push the bit map directly there's no worry about flow control... :-)) VT100s are notorious for requiring *very* strict XON/XOFF handling, especially in smooth scroll mode. > There are UNIX terminal drivers that will continue dumping a lot > of characters to a terminal that has tried to stall by sending a > DC3. The worst offenders are probably those that insist on using > input silo level alarms. Such terminal drivers are broken and > should be fixed. (This is possible, since there are also UNIX > terminal drivers that do this right.) To be precise, the V7 DH11 driver adaptively set the silo alarm level based on how full the silo was when it was last drained. That code pretty much dropped in to the 4.1cBSD DH and DZ drivers. (I remember reading that the RSX-11D/IAS DH and DZ drivers also set the silo alarm level adaptively.) We found that it didn't clear up all the occasional glitches we saw, however; we later profiled the system using the System III/System V kernel profiler (which doesn't do a graph profile like the 4.2BSD profiler but which is claimed to consume little overhead, can be turned on and off on a production system, and drops into the 4.2 kernel with little work) modified only to profile routines running with an interrupt level greater than spl5() level, and found that the system was spending quite a bit of time in interrupt service routines *et al* at elevated priority (if I remember correctly, the disk driver "hp.c" was one of the major culprits) - enough time to delay the interrupt that tells the host that an XOFF came in until after it was too late. The DEC operating systems keep the time spent at elevated priority within ISRs as low as possible; this improves real-time response, and could be applied to UNIX. (Does anybody know if any of the DEC OSes have XON/XOFF trouble with smooth-scrolling VT100s at high baud rates? We saw the most trouble at 19200 baud, which is not supported by a standard DH and is not supported by all DZs either.) > If your users can't be taught that interrupt doesn't automatically > unstall their terminal, then you have other worse problems to > worry about! Try taping "TYPE CTRL-Q" notes on their terminals. DEC's word processors were built out of VT52s, and later VT100s, and PDP-8s; I remember one of their manuals telling the user that if the system doesn't seem to be responding to their typing, they should hold down the button labelled CTRL and typing the Q key... (Which was one reason I insisted that the custom firmware in the terminals we offer with our office automation systems could be put in a mode which prevented the user from typing control keys.) Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy