Le Fri, 1 Mar 2013 11:41:29 +0000, Harry van Haaren <[email protected]> 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 [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
