lkml.org 
[lkml]   [2000]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: a joint letter on low latency and Linux
Date
From
>I don't know what a "specifically RT technique" is and I don't care
>how its done -- if the kernel can promise to always respond to an interrupt
>within some bound, then the kernel offers a hard realtime guarantee.
>And, for what it's worth, my professional opinion is that this is incredibly
>hard to do and never worth doing in a kernel that also wants to offer
>high speed networking, files systems, and guis.

I fully respect your opinion (both professional and otherwise) about
how hard it is to do.

However, I think it would also be an incredibly great thing to do
(i.e. totally worth doing) if it were really possible to accomplish it
in the context of Linux' many other strengths. This is precisely where
BeOS, for example, falls down: phenomenal scheduling response, but
poorer support for all the other good stuff that Linux folk are used to.

>I'm sure Ingo will tell you that his patch is designed to make long
>latencies _rare_ not impossible.

And as I've said, one dropout every few days is fine with almost
everyone. There's very little equipment in the studio I work in that
doesn't have some kind of hiccup like that.

>Goal A:
> I want low latency Linux where typical interrupt response time is
> under K ms and violations are rare -- usually no more than one
> every T hours under such and such a load.
>
>Goal B:
> I want hard realtime guarantees in Linux, but I don't need a full
> realtime operating system, just promise my application's hard
> realtime requirement is met.
>
>In my humble opinion: Goal A is great, Goal B is horrible.

Goal A is my goal. Goal B is "a bunch of crap" as various participants
here would put it.

>> The only subset that has to be RT safe is scheduling. The rest is not
>> part of the central issue here.
>
>Paul: don't use the word "only" to describe hard realtime scheduling.
>That's the absolute heart of hard realtime.

OK, so Victor: is it your considered, humble and professional opinion
that it would be impossible to offer, lets say, 1 failure per 4 hours
of a 2ms interrupt-driven reschedule response time without
implementing "full hard real-time" in the kernel ?

Suppose that we add a couple of assumptions:

* the only threads that matter are SCHED_FIFO
* those threads run in mlockall() address spaces (i.e. no
paging of any part of their address space)
* the number of other runnable threads never rises above N

Do such assumptions make it any easier ? This is important, because in
many of the situations where audio/MIDI folk would be using this
stuff, these (or similar) assumptions are easy to meet.

>> but i continue to maintain that because the audio thread in these apps
>> can be reduced a purely computational process, with no memory, i/o or
>> other system resource issues, it can be solved (not that it *should*
>> be solved this way, but it can be) by using a fully-preemptable kernel
>> that does not satisfy most of the requirements of an RTOS.
>
>And I continue to believe that a fully-preemptable general
>purpose kernel is like a microkernel -- a delightful theoretical concept
>that has been shown by repeated experiment to be a horrible
>practical experience.

No dispute here. That wasn't my point. I was trying to point out that
contrary to some of the claims here, it seems possible to me to solve
this without creating an RTOS. I don't think anybody would consider
IRIX an RTOS, but my understanding is that it can offer scheduling
responses on the order of what we are talking about here.

Again, I am not advocating a fully-preemptable approach. Larry and
other IRIX folk have made the pain of that development effort very
clear, as well as the costs. Its more that I want to try to flush out
the different ways to accomplish the same thing. Larry has claimed
that you couldn't get the performance we need without either

1) making Linux into something very RTLinux-like, OR
2) adding preemption points all over the place

If (1) is the only alternative to (2), I would be happy, as I said
before, to take on some level of responsibility for organizing, or
helping to organize, the maintainance and development of Ingo's
patches so that low-latency requiring people can use solution (2) on
more or less any kernel.

The other notable player in all this, of course, is
MontaVista. However, since they don't seem terribly concerned about
getting their work into the mainstream kernel, its not clear that its
that relevant to the problem at hand.

--p


Of course, technological changes and a smart
>person or 10 may prove me to be wrong, but it's not the kind of
>experiment that would be good to try with the main development tree
>of a production kernel.
>
>
>>
>> --p
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.rutgers.edu
>> Please read the FAQ at http://www.tux.org/lkml/
>
>--
>---------------------------------------------------------
>Victor Yodaiken
>FSMLabs: www.fsmlabs.com www.rtlinux.com
>FSMLabs is a servicemark and a service of
>VJY Associates L.L.C, New Mexico.
>
>

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

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.049 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site