George Anzinger wrote:
I don't see how this delivers any added value to the user. I suppose code running at the kernel level might gain something, but at the user level we still have to deal with preemption latencies, which are the biggest problem (and, aside from messing up the accuracy of the timers, are NOT timer issues at all).
Actually I think the point I'm trying to make can't be fairly conveyed
without providing a lot of background of what can be done with Adeos. I
would suggest that those interested do some digging. Among other things,
you may want to read about RTAI/fusion:
http://www.fdn.fr/~brouchou/rtai/rtai-doc-prj/rtai-fusion.html
http://www.fdn.fr/~brouchou/rtai/modules.php?name=Content&pa=showpage&pid=1
Here's a quote from Philippe on how this compares to HRT:
Last time I checked (i.e. two days ago on a 2.6.6), hi-res timers were
not capable of providing 1Khz periodic timings for 10mn with no overrun
through clock_nanosleep(), even with no additional load on the machine.
fusion is able to do that directly through a plain nanosleep(); in fact
it is able to sustain 10Khz periodic timings with a compilation, disk
I/O and interrupt flooding in the background. Frankly, IMHO, determinism
with really hi-res timing in user-space is a territory which will remain
ruled by RTAI for quite a long time; vanilla Linux will always look
miserable at some point in this respect unless, e.g. stuff like that
(which is otherwise perfectly sound for a GPOS) disappears from its code
base:
kernel/softirq.c:
/*
* We restart softirq processing MAX_SOFTIRQ_RESTART times,
* and we fall back to softirqd after that.
*
* This number has been established via experimentation.
* The two things to balance is latency against fairness -
* we want to handle softirqs as soon as possible, but they
* should not be able to lock up the box.
*/
#define MAX_SOFTIRQ_RESTART 10
asmlinkage void __do_softirq(void)
--
But, hey! I WANT to be able to lock up this box! :o)
Unfortunately, there's no sustained vendor push behind this kind of stuff
as their is for HRT, but my experience has been that this is for lack of
understanding of what Linux can/should be able to provide as a GPOS then
anything else (i.e. a lot of "embedded"/"carrier-grade" vendors seem to