Jonathan Stone <jonathan@DSG.Stanford.EDU> writes:

> 
> >Hm, I've got a 25MHz 386 with 16450s, and I still get silo overflows at
> >19200 baud with the new com driver (well, an older version of it...
> >haven't tried this latest set of patches yet). It's only got 4 megs of
> >RAM, so it does page fairly often (to an IDE disk). 

If you're not using the new version, then that's really not useful
information.

> I've seen good results with frobbing fast-path interrupt handlers. An
> officemate once frobbed the Linux tty code, which *always* does pDMA
> and a fast-path return, polling the pDMA receive list once every clock
> tick (100Hz).  Very efficient, but the extra round-trip latency (up to
> 20 ms) was noticeable. 
> 
> We added a 256-entry boolean array;  receiving a char with the array
> entry true caused an immediate flush of the pDMA queue, via a "slow
> path" exit to, e.g., a ppp softint handler.  LIne sisciplines set
> the array so that end-of-frame chars are true.
> 
> Is there any chance of adding something similar to NetBSD?

Actually, it's completely irrelevant.  The second-level processing is
now done by a soft interrupt that's called ASAP.  There's never an
additional delay (unless your machine is swamped with interrupts).

> It seems to make a  noticeable  improvement, especially on FIFOless
> hardware.

I don't see why that has *any* relevance to FIFOs at all, actually.
What gives you a performance benefit without FIFOs is just getting the
bytes off the chip fast enough; where they go after that is another
issue entirely.