> "Variants" and "Solutions" sections. There seem to be a few
> hard-realtime solutions (unlike Molnar's patch, which gives you
> soft-realtime), but they seem quite hard to implement... haven't tried
> them, tho'.
I have done some development with RTLinux, a hard-realtime Linux
solution, and it is a bit of a pain-in-the-ass to program for, since
you are working in kernel-space and anything wrong you do will crash
the whole computer. however, there is a way of using gdb with it, to
catch errors before they cause a system crash. this makes things a
little easier. and the fact is you can get VERY low latency using it.
However, the project for which I was using it migrated our drivers to
Linux 2.6, and when we did so, we found that we were able to get very
very good timing out of it. This is because 2.6 incorporated the
"preemptive" kernel locks, and when compiled with an HZ value of 1000
(that is, the basic OS interval timer for task switching), we were
able to write code in user mode which had latency of less than 1ms.
(This is including some I/O with a PCI board -- a data acquisition
card to be precise.)
So I would recommend not worrying too much about using a hard realtime
system -- these days "soft" realtime seems to be rather good for most
purposes.
(The difference is that in soft realtime, you have no *guarantee* of
the timing. Something could happen in an unrelated part of the OS that
causes your process to wait longer than usual, and you could miss
something. However, in practise I've found that running under a
properly configured 2.6 kernel, this is rare enough that it's not
really worth worrying about!)
In this particular case, something to watch out for is whether there
is an MMU. I think likely there is not. (Haven't check the linked
docs) You'll probably have to run Linux sans-MMU, meaning that
processes can step on each other if you're not careful! However, it's
not *that* big a problem. Just makes development slightly more
annoying. I don't have any information on latency reports for
MMU-less Linux.
Steve
Received on Fri Jul 28 04:15:10 2006
This archive was generated by hypermail 2.1.8 : Fri Jul 28 2006 - 04:15:11 EEST