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.