lkml.org 
[lkml]   [2000]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: a joint letter on low latency and Linux
In <200007021542.LAA13990@renoir.op.net> Paul Barton-Davis (pbd@op.net) wrote:
>>> I can say only that I tried my best to generate higher than 2msec latency
>>> spikes on a my old P133, but I failed.
>>
>>> I have no mathematical proof that the lowlatency patch provides "hard realti
>>me",
>>> but but empirical testing under extreme conditions show us that works well f
>>or
>>> doing realtime multimedia.
>>
>>It's benchmark. Benchmark is great way to spot the problem but it's not very
>>usefull to prove that you have solution.

PB> Its a benchmark that started life as a real program, and had to be
PB> gradually reduced to "benchmark" status because several Linux kernel
PB> developers don't have soundcards in their systems.

Huh ? Why you think "real program" and "benchmark" are different beasts ?
They are not. Ok. Not every benchmark is "real program" but every
"real program" is benchmark (may be poor benchmark, but it's other story).

PB> If linux kernel folk were willing to install the hardware necessary to
PB> run the "real" programs, I could point them to dozens of them in an
PB> instant, all of which would fail when configured for low latency. But
PB> they are not (which is just fine), and so we have to use "benchmarks"
PB> to demonstrate just how messed up things are.

Once again. Looks like you simple can not understood simple thing: NO
"real program" in the world can prove that solution is good. THE ONLY
thing that can be proved by ANY "real program" or ANY benchmark is
that solution is bad. To prove that solution is good you need paper and
pen, not "dozens of real programs". How you can EVER develop ANYTHING
if you can not understood this ?

>>> The load I created is certainly bigger than the average load of a desktop
>>> system, thus even if the lowlatency patch can not called "hard realtime",
>>> it is SUITABLE for realtime multimedia.
>>
>>If it's good for you then use it ! What's the problem here ? If you want it
>>to be included in kernel... It's COMPLETELY other story.

PB> It certainly is. A much more IMPORTANT story. As has been pointed out
PB> by many people, Linux right now is completely unusable for any "live"
PB> audio or video work, and has latencies more akin to batch processing
PB> OS's of the 1960's, scaled a little for h/w improvements. We would
PB> like to persuade other people to use Linux, because we think its a
PB> fabulous OS in so many ways, but to do that, it has to be able to do
PB> better than the current ridiculous latency characteristics. To fulfill
PB> that goal, its the kernel that has to be fixed, not just telling
PB> people that a patch exists.

Yeah. You are 100% right. "Kernel has to be fixed, not just telling people
that a patch exists". And thus someone should step up and develop fix for
kernel alongside with paper (or .txt, .html or even .doc file - not such a
big difference) where it's explained WHY this solution WILL fix problem.
If you'll say "Ok, it's must be good since I tried 100 "real programs" on
100 systems and they all works just fine" then I (or rather Linus) will ask
"Now what ? Why you think it'll work for 10000 other systems and 10000 other
programs ? Why you so sure that your patch will not deadlock 1000000 other
system where it'll be installed but where audio/video work will not be done?".
If you have non-working system you can be quite sure there is bug in system
somewhere. If you have "working-so-far system" it does not prove anything.

>>> the risk that we could loose 1msec of audio during the next 50 days because
>>> lowlatency is not hardrealtime is not worth to switch to RTLinux.
>>
>>> ... just like saying better not take the plane, it might crash
>>> such is life
>>> :-)
>>
>>> (we live in a statistical world)
>>
>>You - may be. Linus - not :-) That's why Linus works (unlike some other OSes).

PB> The problem is: Linux DOESN'T work unless its OK for your
PB> not-too-far-from-1GHz processor to sit around and twiddle its thumbs
PB> for 10s of msecs while chunks of code that made it through the filters
PB> of this list screw around with lengthy codepaths, spinlocks and IRQs.

It's bad but acceptable for millions of users. If it's unacceptable for you
then you should develop solution (or hire someone who will do such thing for
you).




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