Messages in this thread | | | From | "Khimenko Victor" <> | Date | Sun, 2 Jul 2000 21:00:25 +0400 (MSD) | Subject | Re: 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/
| |