Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!pcserver2!kdenning
From: kdenning@pcserver2.naitc.com (Karl Denninger)
Newsgroups: comp.unix.sysv386
Subject: Re: Son of FAS?
Summary: Consider this scheme
Message-ID: <1991Apr27.231847.8873@pcserver2.naitc.com>
Date: 27 Apr 91 23:18:47 GMT
References: <1991Apr25.010758.1522@pegasus.com> <1991Apr26.013550.20175@netcom.COM>
Organization: AC Nielsen, Bannockburn IL USA
Lines: 67

In article <1991Apr26.013550.20175@netcom.COM> gandrews@netcom.COM (Greg Andrews) writes:
>In article <1991Apr25.010758.1522@pegasus.com> richard@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.
>>
>>Doing away with the interrupt overhead supposedly results in a marked
>>performance gain.  (Seems reasonable.)
>
>Actually, they don't poll with the system processor.  The ports themselves
>probably handled by a dedicated processor on the board itself.  Since that
>processor has (almost) nothing else to do, it can efficiently poll the
>port circuit.  Since the system processor doesn't have to deal with the
>low level byte-in/byte-out of the serial ports, it can efficiently do
>everything else.

Correct.

As far as you go, that is.

The Equinox board, in particular, uses one dedicated ASIC which is
specialized to handle serial I/O.  It uses no USARTS or other "standard"
serial interface chips.  All the logic is in ONE chip.

It is gawd-awfully good at what it does as well.  As it should be -- it was
developed for this and only this application.

>Polling works like the mailbox at your home.  Once a day, you go out and
>check it to see if you've received mail.  Since you only have to poll it
>once a day, it doesn't burn up too much of your time.  The mail comes at
>regular intervals, so you know when to expect it and you don't have to
>continually check the mailbox all day long.

The Equinox drivers and newer Digiboard drivers on the host side use a
derivitive of polling.  They use ADAPTIVE polling.  This takes advantage of
the fact that you really can't tell the difference between a 50ms delay and
no delay in reading characters from a serial port at low baud rates..... and
the driver can "learn" the data rate and adjust it's polling rate.  Also,
polling to check one bit is VERY fast (ie: is there anything in the buffer
that I have to deal with right now).  You can do this from the clock
interrupt with nearly no overhead.

Since the board has buffer memory on it, this works very well.  On each
"tick" the board can be checked for pending input and output buffer
availability.  If there is input pending or output buffer space (and you
have output for the card) you can then set a flag for later -- and when you
get around to it do the actual input and output in a batch.

This turns out to be much, much faster under heavy loads, and is
indistinguishable from the interrupt-at-a-time character mode during light
loads.

This kind of design is directly responsible for being able to run 24 ports
at 38,400 full duplex with NO flow control and no lost characters -- all
with single-digit load impact on the system processor.

I used to do this kind of thing in programmable controllers (where we didn't
HAVE the extra cycles - the "cpu" was a Z-80!).  If it's done right it's the 
best solution available.

--
Karl Denninger - AC Nielsen, Bannockburn IL (708) 317-3285
kdenning@nis.naitc.com

"The most dangerous command on any computer is the carriage return."
Disclaimer:  The opinions here are solely mine and may or may not reflect
  	     those of the company.