serial ports on the '286

[James Van Artsdalen]

In article <532 at micropen>, dave at micropen (David F. Carlson) wrote:
> The PIC (interrupt controller) doesn't "lose" interrupts, it allows them
> to be masked long enough that the 1 deep fifo on the 8250 family is overrun.
> Further interrupt events while a pending interrupt is still flagged does
> nothing to the CPU but the events that they represent are possibly
> irrevocably lost.

This sounds like a distinction without a difference.  I don't care
*what* part is responsible for the fact that a character was lost
("overrun", if that's what you wanted).  All I know is that a
character came, an interrupt was signaled, but the CPU saw neither,
and the character was lost.  Fiddling with the PIC or using CLI are
all the same to a lost character...

> But raw mode is defined (often) to return in *less* than 10 characters.

Specifically, uucp uses a VMIN of 6 when sending data (70 when receiving).
Zmodem defaults to 133.  Who knows what kermit does - it probably sets
up a committee to decide.  :-)

> The "win" of the fifo is that overruns are nearly impossible [...]

That's what I meant to say.  But I also think you underestimate the
load that 2000 interrupts/sec (19.2Kbps) places on the system - the
kernel is rather slow about interrupts.  If you reduce the interrupts
by a factor of 10 or VMIN, whichever is less, you'll substantially cut
system load.  In any program that does sustained high-speed receiving
(such as Zmodem or uucp), VMIN is already set greater than 1 to cut
the potential load of 2000 read(2) calls per second, which probably the
kernel couldn't handle anyway.  bigtex appears to be able 30% loaded
when uucico talks TB+: I imagine it's worse for the 286s.
-- 
James R. Van Artsdalen    ...!uunet!utastro!bigtex!james     "Live Free or Die"
Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746