Subject: Re: [linux-audio-dev] 2.4.0-test8 low-latency
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Wed Sep 13 2000 - 15:09:48 EEST
On Wed, 13 Sep 2000, Paul Winkler wrote:
>> I've also been fiddling around with the latencytest scripts a bit,
> mostly to add an optional sixth argument to choose the directory for
> the temporary files.
> Makes it easier to compare disk performance with different disks. I
> also moved cpu_load into latencytest.h (make it easier to change)
> and changed genhtml to print the chosen value of cpu_load on the
> generated page.
>
> cpu_load turns out to be quite important to me because on my celeron
> 333, 80% usage takes a verrrrry long time to finish (I thought it
> locked the box but it was done when I got back from dinner) and
> outputs bogus results. I gradually tweaked it downward to 76% which
> appears to be the max my system can deal with.
>
> Patch follows. I leave it up to Benno to decide whether any of these
> modifications are a good idea...
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.
One first step for the rewrite was to separate the graphics output from the
latency measurements. This is why I wrote liblatency.
A new latencytest would be quite small from a code POV, since it is basically
- commandline parsing (but this time DECENTLY using getopt_long()),
eg. where you can specify --cpuload=0.8 --fragmentsize=256 --diskpath=/tmp
etc
- audio/RTC setup
- main loop (which calls the functions of latency-graph to record latency
values)
- output of the graph (done via latency-graph)
So perhaps Paul convinced me that it's time for a rewrite.
Regarding the system-stressing methods (stress_diskwrite etc), I think a folder
with the scripts would be ok, so that new stress methods can be added without
the need to modify the mainloop.
Throw in your whishlist (not too complicated pleez) below, so perhaps tomorrow
I will begin to code on it.
Plus I am not familiar with ./configure (autoconf & automake) :
it would be nice that latencytest could detect if libgd supports PNG or GIF and
then act accordingly, since some distros seems to support only PNG while
others stick to the GIF format (Redhat)).
So who can save me from a painful reading of the autoconf and automake docs,
and give me a quick advice about creating a ./configure which detects what kind
of image formats libgd supports.
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.)
So I think for optimal performance a softsynth should not use more than 70% of
the CPU in order to leave some space cycles to the rest of the system.
(otherwise the GUI will begin to feel sluggish and the disk throughput will
suck)
cheers,
Benno.
This archive was generated by hypermail 2b28 : Wed Sep 13 2000 - 14:28:30 EEST