Subject: Re: [linux-audio-dev] lowish-latency patch and toolchain
From: Khimenko Victor (khim_AT_sch57.msk.ru)
Date: Sat Jul 08 2000 - 18:47:00 EEST
In <20000708150210Z31499-532+18397_AT_nic.funet.fi> Juhana Sadeharju (kouhia_AT_nic.funet.fi) wrote:
>>From: Andrew Morton <andrewm_AT_uow.edu.au>
>>
>>doing silly things, the scheduling latency is reliably 4 milliseconds on
>>a 500MHz machine. Very occasionally reaches 7 millisecs. It has been
> Lets talk about 7 ms latency only -- 4 ms is useless information in audio
> software which has to be 101% reliable.
Sorry. It was said 1000 times already but I can repeat once more just for you:
101% reliability => HARD real time => RTLinux. Period. If you NEED 101%
reliability then stop even THINKING about normal Linux already. It's NOT
for you.
> That is poor compared to earlier results 2.5 ms.
It can be expected. There NO WAY IN HELL to include Ingo's original patch
in kernel, so stop talking about it already. It REALLY starting to look like
Gooch/Larry prediction:
-- cut --
My guess is you'll be digging yourself in deeper and deeper,
sprinkling random hacks in random places, as Linus put it.
-- cut --
And when compared to stock kernel it's quite a big win for just six
pre-emption points so perhaps it can be justified (some of them really
look like justifyable points) and Linus will accept them.
> Or can audio input-output latency between A/D & D/A be somehow less than
> 7 ms?
Of course. It's easy. Use RTLinux. You need it anyway (as you said you need
101% reliability) so what's the point of discussion at all ?
>>Here's the current DDT list:
>>
>>- Don't delete huge files (100 megs). There's a hungry
>> loop in zap_page_range which has no clear-and-easy fix.
>> There _was_ a fix in Ingo's patch, but additional 2.4
>> threading has made that unviable.
> That is quite important to get fixed. Only perfectionist such as me
> would reuse files without deleting them in an audio software. The files
> can be very large and very temporary.
Yeah. HUGE files are common in multimedia and life without ability to delete
such files is tough.
> I would like to know the most important points of how kernel works,
Huh ? What's "the most important points of how kernel works" ???
> at what points Ingo added extra scheduling,
Basically Ingo added extra scheduling everywhere where it looked right
on first glance without deep investigation - with just few benchmarks
(AFAIK anyway).
> why it doesn't work now,
Since there are MUCH less pre-emption points.
> why the patch was a kludge.
See above (and track LARGE discussion if you ALREADY forgot it). If you think
THIS patch is not a kludge... You are wrong. It's still a kludge. Linus accepts
kludges from time to time. But ONLY if it's showed that any other sane solution
can not be done in reasonable amount of time (say 1-2 years). Linux is real OS
for real OS and if there are no way to handle problem properly then it'll be
handled with a kludge. But first you need REAL STRONG reason to believe that
there are no sane way to handle problem (big time spent in few places of kernel
without ability to reshedule - NOT "low latency" as whole; "low latency" is just
umbrela name for quite a few problematic parts of kernel).
> Some simple diagram or pseudo code is fine.
If such "simple diagram or pseudo code" existed in first place neither Ingo
patches nor Andrew's research was not needed.
> I could take a look at kernel sources if I would like to learn the
> advanced stuff at the first course. How your patch changes the diagram?
> I would like to help but I have taken only a basic course on kernels.
> But I think receiving patches only from one or two person cannot be
> a good tactic. It might be better to get more people to understand
> the kernel on relevant parts and to think possible solutions.
Then start doing it. It's easy to fix things if you have comprehensive
diagram of dataflow/time wasting. It's MUCH harder to draw such thing.
I'm not sure if it's possible for Linux kernel at all (it's really easy
do draw principal diagram of dataflow in linux but what it'll buy you?
small things like sys_msync() where A LOT OF time can be spent will not
be shown there; and if you'll draw diagram of such a great detality it'll
become useless pretty fast since it'll be just translation for more or less
complete kernel source from C to some other language).
> (I'm reading linux-audio-dev.)
This archive was generated by hypermail 2b28 : Sat Jul 08 2000 - 19:24:12 EEST