lkml.org 
[lkml]   [2000]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: a joint letter on low latency and Linux
Date
> >"All we need is guaranteed scheduling response".  But it's not real time.
> >
> >Those two statements are 100% at odds with each other.
>
> Did you read what I wrote ? Did I say "its not real time" ? I've said
> over and over that I am not interested in this kind of
> classification. I'm interested in features and performance, not
> semantics.

God forbid that we introduce any semantic content into this lovely discussion.

What you are not reading/hearing/understanding is that your requirement for
"scheduler real time response guarantees" has far reaching implications into
the other subsystems that you keep insisting aren't important to you. What
you don't seem to realize is that the scheduler is just fine, it just isn't
getting called when you want it to get called. In order to make it get called,
each and *every* one of those subsystems that you keep saying aren't important
are going to have to be modified so that they call the scheduler when you want
it to be called. Doing that is part of (a *big* part of) what needs to be
done to make an OS have RT behaviour.

Do you see why I'm frustrated with you? You keep saying "I don't need
real time performance, I just need these changes" when in fact, those
changes are _part_ of the changes that make an OS realtime.

The really frustrating part is that you keep implying that it is just a few
changes here and there and 100% of the prior work in the field says that
you are completely wrong. You then say that as long as "it works 99% of
the time" you are happy, which is also complete nonsense. As soon as it
works 99% of the time, you'll be back to say "we are so bloody close to
be perfect, can we add a few more ``small changes'' to get the last 1%".

> I said ""hard realtime" normally *implies* a lot more than we need".

Bullshit.

> The reason why I am not happy with thinking about this as "hard
> real-time" is precisely that: making Linux hard real-time involves
> fixing way more stuff than the scheduling response.

That's where you are wrong. The scheduler is fine. It's all that other
stuff you say doesn't need to be done which is exactly what needs to be
done to make the scheduler be called. You're talking in circles saying
"all I need is XYZ" and "I certainly don't need the changes that will
enable XYZ, those are too hard".

> But nobody here has said anything to convince me that RTLinux is the
> right approach to getting the scheduler to be capable of making hard
> real time response guarantees.

Then you aren't listening.

> I am willing to be convinced of this, truly. However, the example of
> BeOS keeps nagging me. Those guys do claim "guaranteed" response time
> for audio+multimedia apps, but they don't claim to do hard real
> time. So, by the terms that you've helped enforce here, either they
> are lying, or there is some way to do one without the other.

And I notice that you are neatly avoiding addressing someone else's point
that BeOS used to be really zippy and is slowing down over time. Why is
that, do you suppose? Could it be all the grot they have to do to get
that realtime performance? Nahhhhhhh.

-
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.051 / U:0.344 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site