On   Tue, 29 Jul 1997 01:12:29 -0700,
  "Erik E. Fair" <fair@clock.org> writes:


 >I stipulate all you say, with the sole exception that I believe that widening
 >the character processing path is only one part of the problem - the other is
 >those spl'd sections of code. (just as an aside, if we're going to change the
 >tty code interfaces, we should look at V8 streams or the mythical bstreams
 >(not to be confused with the System V "sewers" network API) as one way to go
 >in doing a new interface). 

Yes, yes.  Unless Mike Karels has picked up bstreams again in the last
18 months we can safely assume bstreams are dead.  And streams does
not mean the same thing when shouted.  So stipulated.


 >The Sun3 and Mac68k NetBSD ports already have PDMA,
 >but they still suffer from the overflows from time to time and expanding the
 >PDMA buffer won't help - we're not getting to the hardware fifo fast enough.
 >
 >Expanding a bit more on what my friend had to say, the problem tended to be
 >bursts of characters, which overflow the fifo (silo, whatever) because
 >interrupt response of the OS is delayed too long.

Makes a lot of sense.  Especially if the  serial traffic is network
packets or screen redraws:  those are inherently bursty.

What do the vmstat -i counters say about other interrupt activity
during periods when the FIFO overruns occur? That's where I'd look first.

 >We still need to have some measure of where the system
 >is spending its time when these events occurr...

Granted.  In the absence of anything better, there's always vmstat -i
counters or event counters

 >There will be cases where the hardware is just plain broken in its interrupt
 >heirarchy, and we're stuck with it; the i386 hack you mention (turning
 >interrupts into "events" of a sort) sounds like one way around that problem.
 >I bet those interrupt handlers are really small, too. 

Mpfh.  Actually, I have numbers that suggest the i386 IRQ handlers are
actually pigs, under heavy interrupt load (ie., up to 10Khz, if the
CPU could keep up.)

It's due in part to all the find-first-bit-set instructions, and
looping, and traversing a list to callout to chained interrupt
handlers.  There are applications where I'd prefer a faster,
ligthweight, in-and-out IRQ handler that doesn't support interrupt
sharing.  The i386 port used to have such functions but they weren't
used, and got GCed sometime last year.

Besides, the software-mutex or `memory-based SPLs' technique is Simply
Not Feasible unless you have atomic mutex (e.g., test-and-set) memory
operations, or you can emulate them by enabling and disabling
interrupts very cheaply.

But if you can do that, why do the software-mutex thing in the first
place?


 > Doing things this way,
 >we could even get really kinky and reorder the interrupt processing priorities
 >on the fly, as needs dictate.

Um, why bother, if you can compute the interrupt priorities 
and masks at interrupt-attach time and map them to SPL levels accordingly?
(The pmax port doesn't do this, yet, but I think it's the right
way to go.)

Or do you mean reprogramming the hardware to change the interrupt
priorities -- like the Linux utility that reorders i386 IRQs to put
high-rate devices on the higher-priority interrupt controller?  Ewww.


 >Coincidentally, cleaning up the interrupt latency issue will also make our
 >system clocks more accurate, disks go faster, it's less fattening, tastes great.

Disks faster, tastes great, less cholesterol, yes. But clocks?

Even on a crufty old DECstation 5000/240, my clock runs at under 9ppm
as measured against a stratum-1 NTP server. And that'd be more
accurate if marginally slower if I paid the CPU cycles for a real
divide, instead of approximating division by 1024 by a shift-and-add hack.