Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!feed1.news.erols.com!arclight.uoregon.edu!enews.sgi.com!ames!cnn.nas.nasa.gov!news
From: Hugh LaMaster <lamaster@nas.nasa.gov>
Newsgroups: comp.unix.bsd.freebsd.misc,comp.arch,comp.benchmarks
Subject: Re: benchmarking discussion at Usenix?
Date: Thu, 16 Jan 1997 10:16:38 -0800
Organization: NASA Ames Research Center
Lines: 69
Message-ID: <32DE7085.41C6@nas.nasa.gov>
References: <5am7vo$gvk@fido.asd.sgi.com> <32D18190.369A6C81@informatik.tu-muenchen.de> <5av0jb$aus@uriah.heep.sax.de> <32DAD3AF.15FB@nas.nasa.gov> <5bjt1r$5rg@flea.best.net>
NNTP-Posting-Host: jeeves.nas.nasa.gov
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.0 (X11; U; IRIX 5.2 IP12)
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:33924 comp.arch:62365 comp.benchmarks:18801
Matt Dillon wrote:
> :In article <32DAD3AF.15FB@nas.nasa.gov>,
> :Hugh LaMaster <lamaster@nas.nasa.gov> wrote:
> :>J Wunsch wrote:
> :>
> :>> Bernd Paysan <paysan@informatik.tu-muenchen.de> wrote:
> :>
> :>> > Another part is exception and interrupt handling.
> :>
> :>> Hmm. This can't be expressed in a benchmark, hardly. OTOH, if the
> :>> system keeps reasonable statistics, the effect of interrupt and
> :>> exception handling should be forseeable. I estimate this being less
> :>> than ~ 10 % of the total time on a modern machine.
> :>
> :>I guess it depends on whether or not you have to drive
> :>dumb ugly serial ports and such like. You can spend
> :>a lot of time handling interrupts with such devices.
> :>One paper at Usenix showed Linux on a Pentium dropping
> :>interrupts/data when driving a 115 Kbps serial port...
>
> The ISA bus cycles used to access the serial ports (in most cases)
> are slow, but not THAT slow. Any problem linux has with serial
> data overruns is readily attributable to long interrupt disables
> in other parts of the kernel
Yes, and ... ? I'm not attacking linux, BTW. A particular design
decision was made for reasonable reasons.
and the fact that the PC-standard
> serial chipset is braindead when it comes to on-chip hardware
> handshaking.
The point of the article/presentation, as well as what to do
about it, centered on the the tradeoffs involved with various
strategies, including trading off time lost due to PIIC accesses
vs losing interrupts.
It has nothing to do with the processing
> time required to handle the serial interrupt.
"It has nothing to do with the CPU cycles required to handle
the interrupt." That isn't the same thing as "time". "Time"
is the time lost to an interrupted process when handling lots
of interrupts. There is a direct tradeoff in the PC required
between losing some interrupts and time lost, due to the
"braindead" design [your word above]. There is also a proposed
method which should minimize the number of lost interrupts while
still minimizing time impact. Of course, "real" computers
have hardware that minimizes overhead due to MP synchronization
and due to interrupts. But, most of us use PCs now, not "real"
computers, so, it is interesting that a software technique exists
which can extend the utility of the PC in demanding situations.
> PC serial ports are the exception rather then the rule.
I'm not sure what rule they are an exception to, but anybody
with a PC [almost everybody] who is surprised how "slow" their
PC is when driving a fast modem via a serial port may think such
behavior is the rule rather than the exception. Of course,
many people avoid using dumb PC serial ports for exactly that
reason.
I agree with somebody above that you can't really benchmark
this in userland, but, I consider "number of interrupts/sec
handled without losing interrupts" to be an interesting number
to know about a (hardware/software) system.