>> I haven't heard anybody here who knows anything about BeOS internals
>> call it "a pile of crap", though there have been intimations that it
>> is becoming less lean-and-quick than it was originally.
>
>Let's wait and see. If BeOS is better for you then Linux then use it instead.
Simply because its not open source and not GPL'ed, BeOS can *never* be
better for me. Even if it could do 1microsecond scheduling response on
a 10MHz 80286, it wouldn't be an option for me on philosophical grounds.
If they GPL it and Gtk-- is ported to BeOS, it would be a different
story.
>> In the case of worst-case latency, each of the above 3 operating
>> systems performs better than Linux.
>
>Perhaps. I doubt it in Windows case, though. I've seen quite a few times
>how Windows just started to do something deep inside it it and stopped to
>respond for few seconds altogether. So how ANYONE can even talk about
>latency mesuared in MILLIseconds, not in SECONDS for that beast is beyond
>me.
Well, nobody is talking about it, they're just doing it. Go take a
look at any magazine on "electronic music", and you'll find dozens of
software products that run on Windows and can do anywhere from 5ms to
100ms latency, depending on the depth of the kludges they
introduced. But rest assured: its nearly always based on kludges of
one kind or another.
>And rightfully so. Patch is NOT about "worst-case latency". It's called
>"real-time" and said patch DO NOT provide that. Patch tries to reduce
>linux kernel latency "in most cases" but you STILL will not have GUARANTEED
>"worst-case latency" of 5ms or 100ms. And Larry rightfully said "if you need
>real-time then you need real-time period." Perhaps you DO NOT need real-time
>but then WHAT exactly you need and WHY you think low latency patch will give
>you that ?
I've stated it before. In more real world terms, if we had a real
world situation in which a 1ms dropout occured once every 5 days, I
don't think anyone would mind very much. The thing to remember here is
that nobody is suggesting that a machine that is running as a busy web
server should also be doing real-time synthesis. For the most part,
these are systems where the RT audio app is the only thing in the run
queue 99% of the time, and even when other things are there, its still
the only SCHED_FIFO task.
>Such observation can be predicted and he is not first one who noted this.
>This part was good. But then he concluded that improvement should be enough
>for patch to be applied as "a onfiguration option". Thus showed that he
Once could argue that it has much less effect than SMP, which is a
configuration option too. One could argue that low scheduling latency
has more use in the real world than SMP support (i wouldn't argue
this, since i think everyone should be running at least a dual cpu
system, especially for audio work).
>REALLY can not understood why patch was rejected in first place. For that
>part he was pilloried (sa you formulated it). And rightfully so.
>
>> In response to which you and others have pilloried him as an idiot.
>> If I was you, I would be ashamed of myself.
>
>Why ?
Firstly because pilloring anyone in completely unnecessary. If you
really have to slam someone, better to be like Dorothy Parker, who
could destroy idiots with a witty phrase that sounded like a
compliment until you actually thought about it.
Secondly because he didn't say anything particularly wrong. He told us
that he wasn't a kernel hacker and he might not understand all of the
issues, but that he wanted us to understand how useful the patch was
for him. He did use some slightly unfortunate language, the kind that
typically goads certain people on this list into ad homimen attacks
(the worst/most common example of which is the suggestion that other
people "should" do work for the sake of the author). But that doesn't
make him stupid, or an idiot, and it doesn't justify or help the flow
here to construct things this way.
--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/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:09 EST