>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). 

The Linux machine I was thinking of is the on  CGD saw at SOSP 95
(Copper Mountain) and others may have seen at Usenix 96.
That was an old Gateway 2000 handbook which I think has 16450s.


I can personally vouch that Linux on a slow 33MHz 486 with
16450s can keep up at 38.4 for 1k packet bursts. That was with
fast-path interrupt assembler glue and aggressive pDMA.

Charles says that the *very* latest com.c snapshot does 57.6
on  a `fairly slow' fifoless 486SL.  Kudos to Charles.

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?
It seems to make a  noticeable  improvement, especially on FIFOless
hardware.