Re: Attempted summary of "RT patch acceptance" thread

[Bill Huey (hui) <bhuey@lnxw.com>]

On Sat, Jun 11, 2005 at 12:52:31AM +0200, Andrea Arcangeli wrote:
> Just tell me how can you go to a customer and tell him that your
> linux-RTOS has a guaranteed worst case latency of 50usec.  How can you
> tell that? Did you exercise all possible scheduler paths with cache
> disabled and calculated the worst case latency with rdtsc + math?

Ask Ingo. I'm through with this track and your misinformed comments
about it. We just went through a 300+ plus thread discussing the issues
and you still apparently haven't read through the relevant portions of
it.
 
> Why do you take risks when you can go with much more relaible solutions
> like RTAI and rtlinux?

How are they more reliable ? explain that to me ?

> Said that there are many problems where metal-hard solutions are
> fine, every single app that don't require a worst-case guarantee of
> the worst-case latency is fine with metal-hard, and every time one has
> to call into the alsa ioctl or other complex syscalls also is fine with
> metal hard since the first kmalloc or lock contention inside RT context,
> will send your RTOS into water-hard state.

When you demonstrate a basic understanding of real time programming and
ask a relevant and informed question, then I'll be very happy to explain
this patch, single kernel RT design issues. Until then, I'm declaring
that I'm officially sick of reply to FUD generating comments from folks
that don't understand how this patch works.

bill

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/