Re: RT patch acceptance

[James Bruce <bruce@andrew.cmu.edu>]

Nick Piggin wrote:
> Sorry James, we were talking about hard realtime. Read the thread.

hard realtime = mathematically provable maximum latency

Yes, you'll want a nanokernel for that, you're right.  That's because 
one has to analyze every line of code, and protect against introduced 
regressions, which is almost impossible given the pace that Linux-proper 
is developed.  Then there's the other 95% of applications, for which a 
"statistical RT" approach such as used in the RT patch suffice.  So 
arguing for a nanokernel for (provable) hard realtime is orthogonal to 
the discussion of this patch, and we apparently don't actually disagree.

If you look at your first two messages in this thread however, you seem 
to be offering a nanokernel approach (in particular RTAI as suggested by 
Cristoph) as an alternative to the RT-patch.  This is sort of confused 
by the fact that Ingo called it "hard realtime" because he measured a 
maximum latency during a stress test.  Unfortunately that's not really 
hard realtime if you are just measuring it; Rather its "really damn good 
soft realtime".  An analysis of code paths could be done to determine if 
something really does satisfy hard-RT constraints, but to my knowledge 
that's not on the table at this point.  So you're discussing soft 
realtime if you're dicussing the RT patch.

So its really just a misunderstanding; Nanokernels certainly still have 
a place for some applications even with the RT patches applied (Ingo has 
said as much).  However expecting audio applications such as Jack to 
have to use RTAI is kind of silly, and would end up annoying the authors 
of both (I'm sure the RTAI people have better things to do than support 
ALSA drivers in RT mode).

> What's more, I don't think you understand how a nanokernel solution
> would work, nor have much idea about the complexity of implementing
> it in Linux (although that could have been a result of your thinking
> that we weren't talking about hard-rt).

Nanokernels for RT aren't that difficult when compared with the RT 
patch, I agree with you on that.  An RT scheduler is also pretty damn 
easy to write (certainly easier than a general purpose one that can't 
arbitrarily starve low-prio tasks).  The complexity comes in when you 
have to fork drivers to make them RT-compatible, or upcall into existing 
ones in which case you're making the same modifications to code as in 
the RT patch.  Nanokernels work great for simpler hard realtime apps, 
but poorly for complex softer-realtime apps.  The RT patch addresses the 
latter quite well.

> And my questions for which I got no answer were things like
> "why is a single kernel superior to a nanokernel for hard-RT?",

It's not better; The two methods best serve different types of applications.

> "what deterministic services would a hard-RT Linux need to provide?"

To start out with, nothing; It's better to let such applications develop 
iteratively.  In developing things such as Jack or my robot code, we 
find out what things we can call without screwing up latency, and if we 
think something could be fixed, we might ask about it on LKML to see if 
someone will fix it.  This model works pretty well in open source.  You 
can see my question about the Linux serial driver a few years ago, or 
the many threads about Jack on this list.

I realize you don't like this approach, but that's pretty much how 
things have been working for a while.  The Jack people are using the RT 
patch now, and will come back when they find something that doesn't work 
as well as it seems it should.  They did the same with preempt and the 
lowlatency patches before it.  A fixed set of requirements would be 
nice, but these applications are evolving just as the kernel does.

> Err, your example was "reading a configuration file". Not exactly
> rocket science my good man.

For the third time: One model is easier to program for than the other, 
neither makes anything impossible.  Writing applications in assembler 
isn't rocket science either, but even for "hello world" I'd rather use a 
compiled language.

>> Please explain how a split-kernel method supports a continuous 
>> progression from soft-realtime to hard-realtime, where each set of API 
>> calls has associated latency effects that may or may not be tolerable 
>> for a given application. That's the problem space, and I can guarantee 
>> applications exist all along that progression, and many don't fall 
>> cleanly into one side or the other.
> 
> You say this like you have a confabulous solution ready to plonk
> into the Linux kernel.

I certainly don't, but I think someone else is on to a solution that can 
achieve this eventually.  When someone questioned "who really 
wants/needs this stuff", then I piped up, along with a few others.

Many of us "RT-people" would love to to see the ordinary kernel get as 
far as it can without a radical change in programming model.  That means 
we could write one Posix app that is realtime on Linux, and working but 
possibly not realtime on older Linux versions and other operating 
systems.  We could tell users "use Linux 2.6.14 if you don't want the 
system to hiccup".  That is preferable to writing a special version of 
the software for Linux just to get soft RT.  That said, there will 
always be a place for other approaches such as nanokernels for someone 
controlling the proverbial industrial saw.  For those applications you 
want proof of hard realtime performance, but at the same time they don't 
require streaming data off a disk or onto the network, nor using audio 
hardware or serial radios for output.

[snip part about bothering to understand RT approaches]

I really hope we understand each other now, but if not I guess it wasn't 
to be.  Hopefully someone got something out of reading this discussion, 
but I won't be posting on this branch of the thread anymore either.

  - Jim Bruce