Equinox multi port boards

[John Macdonald]

In article <458 at gallium.UUCP> garyb at gallium.UUCP (Gary Blumenstein) writes:
>
> [ a very favouable review of the Equinox 24 port serial board ]
>
>                                                                 Also,
>I don't fully understand how this board can install without using an IRQ.
>It is advertised as using "polling" and that this makes a faster setup
>when used with a well written driver.  Can someone explain this?

When an interrupt occurs, the system must stop executing the user process
that was being executed, save all register and control information needed
to be able to restart the process that might be affected by running the
interrupt handling routine, invoke the interrupt routine, check whether
a different process has become highest priority because of the interrupt,
and restart the (old or newly available) user process.

If the interrupt is occuring because of an input character from a com
board, then the amount of work to process the input character (the total
time spent in the interrupt handling routine) is generally much less than
the amount of work involved in getting in and out of the interrupt handler
routine (as described in the above paragraph).

Most (if not all) systems have a clock interrupt that is used for controlling
system internal timing functions (like time-of-day, driver timeouts, and user
process alarms).  This interrupt generally occurs a number of times per second
(60 or 100 is typical) - the number is chosen by the system implementors to
provide a good balance between getting the smallest time resolution needed
and putting the smallest possible load on the system with the interrupt
handling.

A polling device driver arranges to have the timer interrupt handler invoke
it occassionally (perhaps 10 times per second).  Since the interrupt overhead
has already been budgeted for the clock interrupt, there is no extra overhead
for the system to invoke the polling driver (except a function call, but that
is trivial compared to the process state saving and restoring).  The polling
driver then checks to see if there is any work for it to do, does what it
can, and then returns to the clock interrupt handler.

This makes the clock interrupt take slightly longer for no reason whenever
there is nothing that must be done on for the polled device.  However, it
saves one or more (possibly a huge number) of process state save and restore
operations whenever there is work that it can do.

A com board's input is an especially good match for this type of handling.
On output you usually can set up a large buffer of characters to send at once,
and this can usually be done so as to only generate one interrupt, so there
is not much difference (although a polling driver can keep filling the output
buffer before it is fully emptied, so there is some gain here).  On input,
however, such buffering is not easily done.  When a character arrives, the
system has no way of telling whether it is necessary to process this character
immediately, or whether it is save to wait a while, so interrupt-based drivers
must usually get an interrupt for every incoming character.  (If the driver
falls behind, it may end up processing more than one character per interrupt,
but in that case the system is being overloaded by the input processing and
cannot continue with anything else until the input level slows down.)  With
a polling driver, there is no need to get an interrupt - the character will
be picked up by the next poll.  If input is coming at 9600 baud, then there
might be 100 characters all processed during a single (tenth of a second)
poll.  At high baud rates, there might be more processed at once.  If multiple
ports are active, more might be processed at once also.  A human user will not
notice a tenth-second delay in echoing (if they do, then the polling could be
done more often).  A machine to machine transmission will normally be done
without echoing, but even if there is echoing, the first character will be
delayed and then both input and output will proceed at full speed.

Of course, a polling device driver is not always the best choice.  To work
well it requires that the hardware be able to take care of itself for long
periods of time.  Thus a com board must have enough intelligence to collect
lots of input characters and buffer them until the polling driver happens
to come along and accept them.  It is generally not appreciated for input
characters to be lost because of insufficient buffering.  It is also desired
that there be enough output buffering to be able to maintain full speed,
since sending one character at 9600 baud every tenth of a second looks much
the same as full speed transmission at 100 baud.  (A processor is not
necessarily required to make a polling driver possible, a UART with 100
character input and output buffers could be handled this way as long as the
polling frequency is high enough to sustain the transmission rate without
loss.)
-- 
80386 - hardware demonstrating the fractal nature of warts.   | John Macdonald
EMS/LIM - software demonstrating the fractal nature of warts. |   jmm at eci386