On 03/01/2013 12:41 PM, Harry van Haaren wrote: Hi! IIRC, Clemens Ladisch did tests like these in the past. Since you have to re-do it for every machine in question, go ahead. ;) The RT guys provide a load script somewhere. I borrowed some of the code for my latency tests, maybe you'll find this helpful: --- cut here --- #/bin/bash while true; do dd if=/dev/zero of=/tmp/bigfile bs=1024000 count=1024; done & taskset -c 0 ping -l 100000 -q -s 10 -f localhost & # repeat with taskset -c N to run on CPU/core #N while true; do du / ; done & while true; do tar cvzf /tmp/kernel.tgz /usr/src/linux-2.6.35/ ; done --- cut --- Maybe too much disk I/O for the typical audio machine, but you can never be sure. ;) HTH

On 03/01/2013 11:41 AM, Harry van Haaren wrote: once upon a time, many many years ago, i had this one: http://www.rncbc.org/archive/old/jack_test4.4.tar.gz untar, make and ./jack_test4_run.sh byee -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

Le Fri, 1 Mar 2013 11:41:29 +0000, Harry van Haaren <harryhaaren(a)gmail.com> a écrit : 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."

On 03/01/2013 12:41 PM, Harry van Haaren wrote: There's a tool to cause jack DSP load: http://subversion.ardour.org/svn/ardour2/branches/3.0/tools/jacktest.c which may or may not come in handy. I've hacked it somewhat for testing CPU freq scaling a while ago: http://gareus.org/gitweb/?p=jackfreqd.git;a=blob;f=tools/busyjack.c drobilla and me did a similar analysis for LV2 plugins. Basically measure the time it takes to process N samples for various block-sizes and input data. The total execution time is only significant for a single machine, however we were interested in variations (error bars). If processing always takes the same amount of time per sample and is independent of the input data, the algorithm is very likely RT safe. Furthermore if there is no significant relationship to block-size that's even better. The scripts and data is available at http://drobilla.net/2012/08/22/benchmarking-lv2-plugins/