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