| What is the latest story on this?  I remember 2 years ago people were
| issuing patches to get around silo overflows and yet I still see them.

I think poor serial performance is a problem with all real Unixes in general.
Linux isn't real Unix, and they did serial right.  Data point: back in the
days of Linux 0.99 and NetBSD 0.8, on a 486DX2-66 with 16450s, Linux
pumped 115.2K solid and NetBSD dropped chars IMMEDIATELY!!!

One "unusual" characteristic of serial ports is that they generate interrupts
relatively frequently, compared to other devices.  A disk seeking at 100
seeks/s generates 100 interrupts/sec, unless you're using a stupid SCSI
driver, in which case it might be 300-500 i/s.  Timer is only 100 i/s.
Ethernet is one interrupt per packet.  Compared to these figures, a
serial port at 115.2K could conceivably generate 1152 i/s!  Buffering
can reduce this figure if the driver is well written.

On the flip side, Unix definitely isn't real-time, and interrupts really
suck.  I think a lot of time is spent in handling interrupts, and checking
for soft-interrupts upon the return of each interrupt.  Unix's poor
interrupt latency, coupled with interrupt-intensive hardware (esp. on
workstations - Sparc/HP-PA serial ports REALLY suck!!!) result in poor
performance.

Some possibilities (I haven't looked at the kernel source, so some of these
may already be done/not apply):

- provide a "fast path" interrupt that doesn't check for softints
- make sure the buffering is properly managed, with low/high watermarks
- ensure path thru serial and line discipline driver is common-case-fast.

Line discipline is something that OS designers might want to re-think.
Most of the time when I use serial ports, I put them in raw mode cuz I'm
running some form of protocol, and I don't want all the line discipline
crap.  I wonder how much that slows us down?