Improving OOTB performance

[Len Ovens]

On Fri, May 18, 2012 6:11 am, Eero Tamminen wrote:
> Hi,
>
> I'm not subscribed to ubuntu-studio-devel list, but I thought
> to comment couple of your recent mails there.

No problem, I have left all of your text in and cross posted this there.

> swappiness setting:
>
> It's a compromise.   If you know that you won't run out
> of memory, things work better with low value (e.g. zero).
>
> If you do run out of memory, larger swappiness value does
> swapping pre-emptively so that you aren't hit so hard when
> you really do run out of memory.
>
> -> Use low swappiness and buy more RAM if it works
>    worse than higher swappiness value.  Or don't keep
>    so many apps open.
>
>    If it works better, but not good enough, make sure
>    swap is on a physically separate, faster media which
>    isn't used by applications you use normally.
>
>    If there's still a problem with swapping, buy a new
>    computer which supports more RAM.

With audio, any swap is probably bad. As I have found out, the first thing
to do is get more ram. The audio trials I have performed seem to show that
I run out of ram long before I run out of CPU cycles. Buying a new
computer is not always an option (the cost of a new audio card alone would
double the price at least and newer MB don't seem to have many or any PCI
slots), maxing out ram more likely is an option. Swappiness is a
compromise yes, but... in audio, swap only keeps the computer from
freezing or crashing. Once swap hits the take is lost or the stage sound
garbled or the synth notes stay on forever. Compromise doesn't help The
memory for the required apps must be there. I think the audio user has to
be aware of what memory they are using and what is left... and make sure
to leave headroom.

> zram:
>
> Sure, compressed cache space is taken from your RAM.
>
> What you need to do, is to check what kind of compression
> rates you get on average.  If the memory compresses to
> half, you "should" be better off with it, as its swaps extra
> disk accesses that typically kill the performance.
>
> Note however that zram behaves *very* differently from swap
> (CPU load instead of disk IO), so Linux memory management
> isn't necessarily well geared towards its use when you have
> completely differently behaving "swap devices" (also normal
> swap).
>
> -> This is something to try *after* you cannot anymore
>    add more RAM to your machine and swap behaves
>    badly despite of fixing above issues.
>
> I would set zram size to half of /proc/meminfo
> (free + cached + buffers) value you have after
> you've disabled normal swap and have computer
> in your normal working state (apps you normally
> use at the same time are open etc).

My experience with zram is that it is like very fast swap. CPU load is not
a problem that I have found because memory seems to be the limit. Example
is my netbook with 1Gig of ram and a 1.6ghz CPU. I start hitting the
memory wall using CPU intensive synths (swappiness 0) yet the CPU load is
only 33% and looking at what "ondemand" is doing the CPU is only running
half speed (.8Ghz) anyway. So zram is not a problem from that view.
However, it is still swap and still slow enough the anything in the audio
chain that gets swapped out (maybe just a sample file that has not been
used for a bit) can stop all the audio till it swaps in again (from my own
experience yes). So zram is not useful for audio as it is still not fast
enough.

Well designed audio apps should try to use memlock, but as I found out,
some don't and it only takes one to put jackd on hold waiting for that
sample. A missing word in audio is hard to hear and on stage may make no
difference, but even a one second delay (with no sound at all BTW) is very
noticeable and may even put that instrument out of sync with the rest of
the band.

For the normal desktop experience xram is fantastic. The swapped out app
just seems slow, not dead like with disk swap. So get more memory first
then use zram.

These are my experiences as I have tried to test these tweaks on both of
my (admittedly marginal) machines. I would love to hear other peoples
experiences with audio applications.

> Pulseaudio CPU usage:
>
> I think there's a tool with which you can request what are
> the current pulseaudio clients.  Some clients might be
> redundantly making pulseaudio to do extra work.  Either
> they shouldn't be connected to pulseaudio at all, or they
> e.g. cause unnecessary audio conversions etc.
>
> Profiling system with sysprof or oprofile is also always good.
> They would immediately tell which pulseaudio plugin/codec is
> to blame as they have different level of performance /
> optimizations and one might be able to use anothe plugin
> or file a bug on upstream about the performance...

Pulse is generally not a problem. Pulse does use a lot of cpu when it is
bridged to jackd at lower latencies. However, in my tests, memory limits
were a problem before pulse could become a problem. Should pulse become a
problem, unloading the pulse-jack module is a quick and easy fix. Stopping
pulse is not needed. If the pulse-jackd bridge is needed for the recording
project, then using a higher latency (try one step at a time) will
probably be the other solution.
>
>
> 	- Eero
>
Anyway, very good points, thank you for posting.

Len
-- 
Len Ovens
www.OvenWerks.net