It should be possible to do considerably better than this.  Note that on
small (486 class) x86 PC's RTLinux achieves interrupt latencies <15usec.

Real time devices need a special purpose interrupt path; the rest of the
kernel being in a coherent state shouldn't be a necessity for time-critical
interrupts to be serviced.  You just need a seperate message queueing system
which handles atomic commitment properly that can dispatch the data to user
space.  (Getting acceptable degrees about context-switch latency and runtime
for real-time processes is a completely different matter, so the queues don't
fill).

Mike

On Tue, Nov 13, 2001 at 09:45:55PM -0500, der Mouse wrote:
> > Controlling robots and machines using a real-time operating system is
> > allways an interesting topic.  [...NetBSD...how it's not very
> > real-time in this sense...500us-100ms max interrupt latency...]
> 
> Short of just using an overmuscled CPU that can do more than you'd ever
> want to in one control cycle, there isn't much to do but use another
> CPU.  NetBSD has some SMP stuff, but it probably won't be much use to
> you, since your task is decidedly *a*symmetric.  Back in the days of
> MicroVAX-IIs and 4.3BSD, I built a microkernel to run on a slave CPU in
> a uVII.  While I am inclined to doubt this would be of much direct use
> to you, some of the lessons learned might be of interest.  (If 4.3 can
> do it, NetBSD probably can. :-)
> 
> I can put you in touch with the person who did the project (all I did
> was write the microkernel to run on the slave CPU), if you want - he's
> now a professor at another university.
> 
> /~\ The ASCII				der Mouse
> \ / Ribbon Campaign
>  X  Against HTML	       mouse@rodents.montreal.qc.ca
> / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

-- 
Michael P. Lyle
Chief Technical Officer
Recourse Technologies, Inc.

The contents of this message are confidential.
Copyright 2001 M. Lyle