Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!AHWAHNEE.STANFORD.EDU!dcrocker
From: dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Super Cheap IP router (< $1000)
Message-ID: <8904140206.AA10084@ucbvax.Berkeley.EDU>
Date: 13 Apr 89 13:53:08 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 33

Henry Spencer asserts that interrupts need not hurt performance, if software
is written properly, primarily through the use of low-level modules to do
the real-time servicing, deferring the rest of the processing for upper-level
software.

Well, five years ago, I would have agreed.  I used to deal almost exclusively
with application-layer protocols.  Working in the lower layers has been
sobering.

Interrupts kill.

The raw machine processing time -- i.e., hardware instruction cost -- for
interrupts is quite significant.  As with most features in this world,
interrupts are excellent for their intended purpose and questionable for
other situations.

An interrupt is very useful when you don't expect much activity and don't
want the overhead of polling.  On the other hand, if you DO expect heavy
activity, polling is quite nice.

Some folks I used to work with did a calculation of the interupt overhead
for 8 terminals running at 9600 baud, using an 80186 processor (I believe
at 6MHz) and discovered that they would have time left over for VERY few
instructions per character.  With a polling approach, they were able
to sustain a data rate of about 14Kbps per terminal.  (My memory is
fuzzy; it may have been around 17000 baud, but you get the idea.)  This
was with appropriate processing for an ethernet protocol stack and
per-character terminal-oriented instpection and modification.

Many, occasional sources of activity warrant interrupts.
A few, active sources warrant polling.

Dave