Son of FAS?

[Bill Kennedy]

richard at pegasus.com (Richard Foulk) writes:
>I recall hearing that Equinox (or someone like that) equips their
>smart serial card with a driver that doesn't use interrupts.  They
>do some kind of polling from within one of the kernels inner loops.

Polling is quite common on interfaces with a heavy load or a lot of spigots.
I think (don't know because I don't have one) that Altos polls their multi
user I/O cards, i.e. 64 user systems.  It imposes considerable processor
burden but it scoops up the stuff that's just roaring in and out.

>Doing away with the interrupt overhead supposedly results in a marked
>performance gain.  (Seems reasonable.)

It does seem reasonable if you're dealing with a gawd awful interrupt
architecture like Intel and living with abysmal interrupt controllers
like the 8259.  On a system with decent context switch time and some
adequate hardware (meaning don't make the processor work extra just to
use the part) it makes sense to be thrifty with interrupts.  The 80286
is probably one of the worst on earth.  On a 6MHz AT&T PC6300 PLUS you
can't handle a steady stream of async characters >4800bps.  If you plan
to do much of anything else, 2400bps is max.  They document 1200bps as
max.  With something like the NS16550A where you can meddle with the FIFO
threshold you can make a 9600bps stream interrupt at the same frequency
as a 2400bps connection without FIFOs.  The overhead is stopping what
you're doing, saving the machine state, deciding where to go and getting
there.  The memory and I/O events while you're there are "free".

>My question is: couldn't this same technique be used to good advantage
>with the fifo-ized dumb serial cards?
>
>Since most smart cards gain mostly from the reduced interrupt load they
>place on the system wouldn't this blur the difference a bit more?
>
>-- 
>Richard Foulk		richard at pegasus.com

I heard that DigiBoard's latest stuff doesn't interrupt at all.  Sure, you
could poll dual ported memory and any number of things, but the easiest
thing to do is manage your FIFO threshold such that you take as few interrupts
as possible while servicing the maximum number of I/O events.  The 550A is
still going to interrupt after a period of "quiet" with a character in the
buffer.  What makes a whole lot of sense is to service every part you can
get to during the interrupt service for the one who interrupted.  By that I
mean if there's any output to do and the port is ready, send it the next
byte and collect all input and queue it for the top level routine as long
as any port has input available.  You spend a few cycles but not as many as
you would if each event required a separate context switch.

The old Z80-SIO was a pretty good example of a part designed with interrupts
in mind.  If you were using it in async mode it used the two bytes that it
kept for SDLC CRC as a FIFO.  That meant that as long as you grabbed the
first character before four characters had arrived, you were safe.  They also
have another thing called "auto-enables".  Like any hardware feature there
are two sharp edges on the blade.  When you set auto-enables you would not
get a receiver interrupt unless DCD was true and you wouldn't get a
transmitter interrupt unless CTS was true.  That sounds like an ideal thing
to do but it had as many drawbacks as blessings.  I've run some pretty high
speed stuff with hardware handshaking through an SIO and it was a pleasure.
At the same time, "pleasure" has twice as many syllables as most of the words
I had for auto-enables when I really didn't need them but used them anyway.

Polling makes sense when you know that you always have a lot to do.  If you
don't or aren't sure, then interrupts help you decide.  I don't, for example,
enable FIFOs in a '550A unless the baud rate is > 2400bps, you don't need it.
If you become heavily loaded it might make some sense to stop interrupting
and start polling until things calm down.  Anybody want to write an async
driver _that_ smart? :-)
-- 
Bill Kennedy  internet  bill at ssbn.WLK.COM or ssbn!bill at attmail.COM
              uucp      {att,cs.utexas.edu,pyramid!daver}!ssbn.wlk.com!bill