Re: [LAD] JACK and CPU stress testing

Le Fri, 1 Mar 2013 11:41:29 +0000,
Harry van Haaren <harryhaaren@gmail.com> a écrit :

> Hey all,
>
> I'm currently attempting to stress test my setup of -rt kernel, rtirq
> scripts, and a Jack client program I've been working on.
> So my idea is to create a script that runs the programs, and also a
> cpu-load generating program (cpuburn or alternative).
> Then collecting stats based on Xruns, % DSP load, etc.
>
> I intend to show (trough brute force) that an application is RT
> capable on machine X with a latency of Y ms.
> Of course this won't be 100% representative, but the stats will show
> some RT-safe-ness.
>
> Has anybody done this kind of profiling / stress testing with JACK
> before? Hints / tips / advice / etc welcomed! -Harry

On my old mono-processor machine, the following was working very well.
Start jackd and some other software that will load it. Start amule and
begin to download a lot a files (more you can, faster amule will
crash). Amule will consume all the cpu under a very long time. On my
mono-processor with a rt kernel optimized for audio, jackd was runing
without any kind of problem at the same time than amule.

The things begin to be very bad when amule will start. This begin with
ed2k-kademilia that get lost, consume all the ram and begin to swap
like hell until it crash. During the swapping, jackd was working. But,
you have 2 possibilities on a mono processor machine: the system will
crash with ed2k or not.

When the system was not crashing, a lot of other software was crashed,
inclusive parts of fvwm. But in most cases, jackd was one of the
surviving pieces of software. Of course, when the system was crashing,
jackd was crashing too... Only the power button was still working.

On a multi-processor, this behaviour of amule is much more difficult to
get, and even if you success to crash it, it will not be a problem for
the rest of the system.

Also, amule act like a server, which need the inverse optimisation than
jackd. jackd is about low latency, a server is about throughput.

# # # # #

On my multi-processor machine, the best stress test I made was to
compile hugin.http://hugin.sourceforge.net/
The 4 cores of my box get very busy with it (around 100 % and a lot of
disk accesses). I use gentoo, portage compile every thing, and this
software is the most cpu intensive I know to compile. libeoffice take
much longer to compile, but it is less cpu intensive.

Dominique

-- 
"We have the heroes we deserve."
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev