>From: "Khimenko Victor" <khim@sch57.msk.ru>
>>>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%
Forget that 101%.
The most above quote tells me that scheduling latency is practically
reliable with 10 ms latency (while taking account those not-to-do's).
If only 7 ms peaks are observed, it looks 101% reliable to me.
It would be very silly to talk that Linux would have 1 ms latency
if it reaches it only once a week. Get the point? Lets not talk about
4 ms latency but 7 ms from practical point.
Development point is that 4 ms is reached at most of the time and somehow
we should get those 7 ms occasional latencies away. Remember, this was the
situation before Ingo's patch, and I'm sure we reach the reliable 4 ms
latency.
>> 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
I was not suggesting that. We should look at a possible good way to solve
this problem. I'm not happy with 4 ms audio-I/O latency, but it could be
reached. I'm willing to dig in to this mess just in case more people means
more suggestions, at least in this case.
>-- cut --
>My guess is you'll be digging yourself in deeper and deeper,
>sprinkling random hacks in random places, as Linus put it.
>-- cut --
My own audio code design is a far from a hack. Everything is very well
organized, well thought. I would like to see if I'm able to say my opinion
in kernel's low-latency matters from non-hacker's point of view.
>Huh ? What's "the most important points of how kernel works" ???
How about telling what are those 6 points where the patch additionally
schedules? A good start. You don't need to give me a full lecture.
>Basically Ingo added extra scheduling everywhere where it looked right
>on first glance without deep investigation - with just few benchmarks
>(AFAIK anyway).
Yep. I would like to see more scientific analysis, and would like to help
on that.
>Since there are MUCH less pre-emption points.
Were they choosed the same way than Ingo choosed his points?
Empirically based on a program analyser whatever...?
If yes, we at least have a way to improve if this patch is ignored
as well.
Yes, I think Ingo's patch is kludge, and wonder if this new one is
another kludge.
>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?
Hey, I just wanted a short cut for understanding the issues related to
low-latency audio, not the full lecture on kernel design.
Juhana
-
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 : Sat Jul 15 2000 - 21:00:09 EST