I have made some Linux kernel changes that I'd like to contribute to
public distribution but I don't know how to do it or who to ask.
One is a driver for Metricom's packet-radio network interfaces. It's of
limited interest to general users, because it only works with Metricom's
radios, but if you have one of those then it is fabulous, giving you
continuous wireless IP access at about 30kbit/sec, 24 hours a day, with
no per-minute connect-time charge. (More information is available at
http://plastique.stanford.edu/mosquito.html)
The other is of more general interest. In the process of writing the
driver for the Metricom radios (which plug into the serial port and
run at up to 115kbit/sec) I discovered that data received on the serial
port is regularly delayed up to 10ms before it is delivered.
Although Linux can run the serial port at 115kbit/sec without any
difficulty, the problem is that the serial port interrupts are currently
programmed as "fast interrupts", and that means that the kernel doesn't
actually DO ANYTHING with the data until the next timer tick, which can
be up to 10ms later. 10ms may not seem like a long time, but for a
network device, an extra 20ms added to the round-trip delay is not
insignificant. Put another way, at 115kbit/sec 20ms is equivalent
230bytes, which could be several IP packets. Declaring the serial
interrupts to be "slow" interrupts is probably unacceptable because
of the excessive interrupt overhead it would cause at 115200 baud
("fast" interrupts are there for a reason, after all).
In an attempt to remedy the problem, I've made a new kind of interrupt
handler in include/asm-i386/irq.h. Instead of a "fast" or "slow"
interrupt handler, it is a "smart" interrupt handler. If the interrupt
routine returns zero, then the assembly code glue takes the fast return
path, like a "fast" interrupt handler, but if the routine returns
non-zero, then the assembly code glue saves the remaining registers and
takes the system call return path, like a "slow" interrupt handler. The
idea is that my modified serial port driver normally returns as a "fast"
interrupt, but if it sees an end-of-packet marker in the data stream then
it takes the "slow" return path, causing the data to be processed that
the receiving process to get rescheduled immediately. Obviously in the
finished version, you'd be able to specify in software what character the
serial driver looks for as it's special "priority attention" character.
I don't see any reason why the SLIP or PPP drivers couldn't also take
advantage of this feature to save up to 20ms off their round trip delays
too. With faster modems and ISDN lines becoming more common, I think that
this kind of software overhead which was negligible before is going to
become increasingly difficult to ignore.
Does this sound like a good idea? Do you think I have any chance of
getting it accepted into the main distribution?
In the long term, we chould get rid of notion of "fast" and "slow"
interrupt handlers altogether, and make all interrupt handlers be the
new kind. All it takes is the addition of a "return 0" or a "return 1"
at the end of the routine.
Stuart Cheshire <cheshire@cs.stanford.edu>
* <A HREF="http://ResComp.Stanford.EDU/~cheshire">World Wide Web Page</A>
* Stanford Operating Systems and Networking Group Research Assistant
* Stanford Residential Computing Associate
* Macintosh Programmer