Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!amdcad!rpw3
From: rpw3@amdcad.AMD.COM (Rob Warnock)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: interrupt-driven vs. polled I/O performance
Message-ID: <25231@amdcad.AMD.COM>
Date: 15 Apr 89 04:59:46 GMT
References: <14-Apr-89.114221@192.41.214.2> <416@logicon.arpa>
Reply-To: rpw3@amdcad.UUCP (Rob Warnock)
Organization: [Consultant] San Mateo, CA
Lines: 55

In article <416@logicon.arpa> Makey@LOGICON.ARPA (Jeff Makey) writes:
+---------------
| In article <14-Apr-89.114221@192.41.214.2> amanda@lts.UUCP writes:
| >When I first saw the code to the UNIX tty handler, my first question was
| >"why are they doing all of this at interrupt time?"  So far, I've never
| >seen an answer to that besides "historical reasons."
| The reason "all of this" gets done at interrupt time is performance,
| although not the kind that has been discussed so far.  In this case,
| UNIX software is responsible for echoing characters, and to keep echo
| delay to a minimum the character(s) actually echoed are put on the
| output queue at interrupt time.  Anyone who has used TELNET (hah!
| there's the relevance to TCP/IP) over a slow connection knows how
| annoying delayed echo is.  :: Jeff Makey
+---------------

But the echo delay doesn't need to be kept to a *minimum*, but only
well below the objectionable level to the human user. And the difference
between those two scenarios can be a *large* fraction of your machine,
especially when you have a TTY driver that is used by both humans
and (say) UUCP at 19200 baud.

A *very small* delay in input processing -- the amount you get when
you use the two-level interrupt scheme Amanda referred to -- can save
enormously in overhead on your high-speed input lines, without ever
being noticed by your users. Likewise, a *small* delay in beginning
output (to give the upper levels time to copy more data into the output
queues) can result in large improvements in efficiency, again without
being noticed by users.

What numbers are we talking about here? Well, at Fortune Systems we
delayed input by 1/60 second (the queue built by the 1st-level handler
wasn't passed to "tty.c" until the next clock tick), and TTY input
capacity went up a factor of 12. In a certain release of TOPS-10
[6.04? I forget], DEC delayed beginning output until the next tick
[4 ticks?], and the output rate went up by a factor of 4 to 6.
Yet both of these systems had "crisp" echo.

I claim that 100ms for echo is not noticable to a user of a video
display (although it is mildly annoying if you are on an ASR-33 (!)
or any other terminal which causes an audible signal on output),
yet allowing the operating system that 100ms or so can result
in such performance gains that not to do so is gross negligence!

Interrupts are ugly, brutish things, to be sure. ("Nyekulturny!" as
the Russians might say.) But they have their uses, especially when
you'd like certain things (like echo) to happen reasonably on time.
But the key is "reasonably"...


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun}!redwood!rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403