Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wasatch!cs.utexas.edu!uunet!mcvax!inria!mirsa!huitema
From: huitema@mirsa.inria.fr (Christian Huitema)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: interrupt-driven vs. polled I/O performance
Message-ID: <164@mirsa.inria.fr>
Date: 25 Apr 89 16:49:05 GMT
References: <421@logicon.arpa>
Organization: INRIA, Sophia Antipolis. France
Lines: 31

From article <421@logicon.arpa>, by Makey@LOGICON.ARPA (Jeff Makey):
> In article <25231@amdcad.AMD.COM> rpw3@amdcad.UUCP (Rob Warnock) writes:
>  [...]
>>I claim that 100ms for echo is not noticable to a user of a video
>>display
> 
> Your point about only needing to keep echo delay below the level of
> perception is well taken.  However, 100ms is 1/10 second, which I am
> sure I would find quite noticeable (my terminal runs at 19,200 baud).

Just analyse a few very popular pieces of software:

	ksh,
	emacs,
	X-Windows,
	...

An interesting point is that all of them are making the echoing from the
user level program! Moreover, X-Windows even send the data on a secundary
TCP connection and back before processing it. And the look at all ``virtual
terminals'' based on the ``pseudo-ttys'', which feature an extra hop inside
the user level before going to the network... Thus, I have some doubts that
one should aim at interrupt time echoing just for the sake of optimizing
``ed'' and ``bin/sh'' if user level echoing is felt acceptable otherwise...

Moreover, by using a conjunction of minimal real time interrupt handlers +
properly scheduled software interrupts, one maximises the system throughput
and thus reduces response times and echoing delays for all users, ``ed'' as
well as ``emacs''.

Christian Huitema