Subject: Re: [linux-audio-dev] streaming with 2.4.0test11
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Wed Nov 22 2000 - 13:00:40 EET
On Wed, 22 Nov 2000, Paul Barton-Davis wrote:
> >But, but, basicly the same idea. Now on to the problem. Most of the time
> >running my test stream (32bit-10ch-44kHz, not much but good for basic
> >testing) goes smoothly. I can stress both cpu- and disk-wise and the
> >buffer-area stays full. But in some circumstances ('find /', and few other
> >heavy io-operations), the audiothread (speaking in lad terms :)) starts to
> >dominate and eats away the whole db-area (that's upto 1-2secs of audio!).
> >The same happens with SCHED_FIFO scheduling. Even changing the relative
> >priority or audio and disk threads, or adding sched_yield()s doesn't seem
> >to help.
> >
> >Now I suspect I'm just running out of disk i/o capacity, although it seems
> >odd that processes running as normal user without rt-priority can choke
>
> wait kai - are you running the thread that does the disk i/o with
> SCHED_FIFO ? because if not, surely its not suprising that other
> disk-ful activities can choke the disk thread, and thus cause the
> audio thread some problems.
>
> --p
I think that even with the disk thread running SCHED_FIFO, these stalls cannot
be avoided:
if you look at a hdrbench's output graph on my machine (using a 2.2 kernel)
http://www.linuxdj.com/hdrbench/graph-18-18.gif
you see that the system uses up to 160k samples (32bit) which means
that at a rate of 44kHz, the disk thread stalls up to 3.6sec.
So the 1-2 secs stalls Kai is experiencing, should be quite "normal".
Jens Axboe (one of the linux-ide guys) once showed me hdrbench diagrams
(using his own kernel patches) which helped to cut these peaks to a 1/2 - 1/4
of those produces by standard kernels, but I'm not sure if his stuff made it
into the 2.4-test kernels.
Anyway I understand that it is a mess to use hdrbench in its current incarnation
since it requires you to set up the tracks manually etc etc.
I hope that in future I can probide an easy-to-use version where one simply
supplies a few parameters to the commandline, runs the benchmark and after
it terminates he can see the graphs and performance numbers.
Perhaps then chances will be bigger that kernel developers will use it to tune
the kernel's disk performance.
Benno.
This archive was generated by hypermail 2b28 : Wed Nov 22 2000 - 11:59:55 EET
