Subject: Re: [linux-audio-dev] 2.4.0-test8 low-latency
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Wed Sep 13 2000 - 16:02:24 EEST
On Wed, 13 Sep 2000, Paul Winkler wrote:
> Benno Senoner wrote:
> > Latencytest sucks in the current form, my plans are rewriting it from
> > scratch, but because of lack of time and lazyness it did not happen yet.
>
> Understood. I figured my patch might be a useful stopgap.
> My changes were just things that seemed nice to me...
I will implement the changes you made,
any other wishes ?
Anyone ?
>
> > PS: Paul, the thing with the 80% CPU usage is true:
> > the more CPU you consume, the worse the overall system performance,
> > disk IO included (this is almost inevitable since there is no CPU left to
> > process the data read from/written to disk.)
>
> It seemed odd to me that there was such a sharp threshold: setting
> it to 76% the test runs fine; setting it to 77% the test takes about
> 30 minutes to finish and the output graphs show perfect performance,
> when in fact what seems to be happening is that the stress code
> takes over the system entirely, and then when it finally finishes
> latencytest is testing a lightly loaded system (until the next
> stress test).
The problem is that during the latencytests, the IRQ rate is very high
(either audio or RTC), and this can eat an additional few % of CPU
especially on slower machines.
TO this add the IRQs generated by disk I/Os, write cache
flushing etc, and you end up on a system which is stressed to death.
:-)
The latency benchmark has priority (SCHED_FIFO) over the outside stress code,
thus the stress code gets only what's left in terms of CPU cycles.
So it should not matter much if you run with CPU load=80% or 60% in terms
of the latency graph, but it will make alot of difference in terms of disk IO
speed, especially during the write tests, since it involves the processing of
large
buffers in RAM which eat CPU too.
The next step would be to create a latencytest tool which varies the CPU
load and measures when things begin to get ugly (eg big disk performance
degradation). This such a tool one could tune the machine and limit the
CPU usage by the audio apps in order to get optimal performance.
Benno.
>
>
> --
> ................. paul winkler ..................
> sslinkP arts: music, sound, illustration, design, etc.
> web page: http://www.slinkp.com
> A member of ARMS: http://www.reacharms.com
This archive was generated by hypermail 2b28 : Wed Sep 13 2000 - 14:58:58 EEST