Subject: Re: Serial port driver
To: None <current-users@NetBSD.ORG>
From: David Jones <email@example.com>
Date: 06/01/1997 17:33:26
| 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
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?