Montavista's "Open Source Real-Time Linux Project" again

Thomas Gleixner tglx at
Fri Oct 15 10:20:43 CEST 2004

On Fri, 2004-10-15 at 02:18, Karim Yaghmour wrote:
> Thomas Gleixner wrote:
> > Yeah, I know. I doubt that. 
> You doubt which part of what I said?

".. want to go ahead and show that it is deterministic, they can."

Show ? With a scope ?

> > Provide a static codepath analysis for all execution paths and I might
> > buy your arguments.
> Right, and then you have the nerve to lecture me about self-adulation ...
> I don't have the time to do this myself, but I'd really love to plug a
> scope and a function generator to machine and compare the VP patches and
> RTAI under very high stress. This certainly would certainly be food for
> thought for everyone involved.

And the scope does what you argued in a LKML thread and what I asked for
"And this has been demonstrated mathematically/algorithmically to be
true 100% of the time, regardless of the load and the driver set?"

That's why I was saying "blah". Provide the things yourself to prove
your point, before asking others to provide them.

Here are the LibeRTOS/KURT (2.4) numbers on the same machine (300MHZ
Pentium) compared to RTAI in a long run test:

IRQ latency for a self contained IRQ
                RTAI            LibeRTOS
No Load         7,8 usec        7,8 usec 
ping -f         8,6 usec        9,8 usec 
hackbench       12,6 usec       11,8 usec 
hbench + ping-f 13,6 usec       13,4 usec

Userspace latency
                RTAI LXRT       LibeRTOS
No Load         18,92 usec      20,45 usec 
ping -f         19,10 usec      21,14 usec 
hackbench       33,10 usec      35,16 usec
hackb + ping -f 34,56 usec      35,40 usec

I don't claim to have a static codepath analysis for that, but those
numbers certainly arent food for your arguments.

Maybe they are food for objective thoughts about different approaches
and their (dis)advantages.


More information about the Rtai mailing list