Performance benchmark & stressing the hardware

7 replies [Last post]
dx9s
User offline. Last seen 9 weeks 5 days ago. Offline
Joined: 2006-05-19
Posts:

I remember finding some tools (forgot names could perhaps re-find them) that stress / benchmarked a Linux OS -- but only the high-level disk I/O (nothing but fopen/fwrite/fread/fclose) ... nothing low level! This is the best way to test anyways!

After revisiting some of the performance stuff on this website and remembering my dubious flirtation with setpci (which improved performance some) but was entirely blind luck for the most part... this leads me to the idea of a more "serious" benchmarking of two or three components involved with Ardour

(all three)

1) Sound performance
2) Disk performance
3) Video performance

Has anybody visited the idea of a mini-ardour-like benchmark+stressing program!?

Such a program should using the Jack daemon for access to hardware so you can also test your settings there. It should capture (and discard?) and playback (pink noise?) to all channels at the same time reading and writing to many files (user selected, like pick 25 read/25 write). It would create 25 "tracks" (broadcast wave files, 32-bit floating), then proceed to capture/playback audio and then read those tracks while writing more.

This would be the core program, to push bits (bytes) of dates around -- a lot of data to stress the machine.

An additional parent program would be something that scans IRQs, and PCI settings and make suggestions, test them, compare agains other settings and save the results. (for a particular level of "Stress"). Additionally, (optionally) screen updates (such as simulating sliders or level meters, etc.) ... Not sure all what should be included.

The goal is a program that can be command line set for various levels of disk, jack (sound) and video stressing. And a parent program that scans hardware and suggest changes and benchmarks changes (so you know if a change is better or worse!)

Just an idea. I hate to get into it, but I could attempt to write some of it however I am not a good C++ programmer (been lazy and using scripting languages like Bash and PHP now for too long).

I am not good at GTK, only done superficial SDL programming, and no sound (with or without Jack). I think something like this would be helpful!

This is just an idea.

--Doug

Markinoko
User offline. Last seen 6 years 46 weeks ago. Offline
Joined: 2006-04-09
Posts:

This could be made possible by separating the ui and ardourlib. One could create a "special" ui that creates a session, uses ladspa plugins to generated noise as input, other generic ladspa plugins to optionally increase system load and make some mesures to see what performance we get, xruns, latency, max number of simultaneous recorded tracks, etc.

Marc-Olivier Barre,
Kinoko en Orbite.

dx9s
User offline. Last seen 9 weeks 5 days ago. Offline
Joined: 2006-05-19
Posts:

thanks

The point is that there ARE too many variables. AMD K7? K8 (amd64), Intel P4?, northbridge, southbridge, pci latency, IDE versus SCSI versus IEE1394, etc.

I believe that a "BASIC" level of stressing that covers the three topics. The fourth one (as you have hinted at), would be raw CPU performance (aka plugins, aka DSP "load") -- I don't think stressing the CPU using LADSPA plugins is necessary and I will explain why below.

If you test the three with a similar program that calls Jack and everything and perform the basic of most basic I/O (disk, jack [sound card], video)... Once the system is stable and fast and so forth, using the core Ardour w/ plugins should not be a problem and the only limiting factor is "DSP Load" which will be the only significate variable once the hardware is good.

Faster CPU = more plugins, but even the fastest CPU cannot overcome disk performance issue or sound card problems.

Understand?

--Doug

Markinoko
User offline. Last seen 6 years 46 weeks ago. Offline
Joined: 2006-04-09
Posts:

But I believe the two aproaches would give interresting results. My idea of this benchmark would be a more "3Dbench" like, testing overall performance and giving out a score, and of course, the result would be related to the user's machine design (chipset, CPU, memory, quality of his coffee mug...).
Comparing different score while looking also at the hardware used for the test would make an interesting database :-)

So if we sum up all our ideas here, we could have a set of specific tests (disk performance, sound card performance, and why not even sound card quality ?), and another set designed to grab the overall performance on a system (useful to the user to help him choose his hardware, and helpful to the dev's to identify on which kind of hardware some optimization could be done, etc.)

Marc-Olivier Barre,
Kinoko en Orbite

dx9s
User offline. Last seen 9 weeks 5 days ago. Offline
Joined: 2006-05-19
Posts:

Yes both would be nice, but the first is more (or less) necessary from a functional standpoint. The CPU performance usually can be summed up like this: AMD's have better FPU! (heheh) Seriously, I have P4 Mobile (in portable) and it sucks for Ardour performance (Intel Chipset, etc.). Perhaps I am spoiled with my other AMD machines w/ Ardour. Several K7's and one K8. And all have nVidia chipset (nForce 2 and nForce 4).

--Doug

zitoune@ardour.org
User offline. Last seen 7 years 42 weeks ago. Offline
Joined: 2006-06-12
Posts:

i'm intrested to know what is the best architechture/processor for Ardour (dsp performance)...

dx9s
User offline. Last seen 9 weeks 5 days ago. Offline
Joined: 2006-05-19
Posts:

In answer to what hardware.... In MY opinion, AMD K7's or K8's with nForce chipsets. I would recommend CPU's with (in order of importance) socket AM2, socket 939 (or 940*), socket 754, and socket "A" based CPUs from AMD.

If you can get an AMD XP 3000+ (for example) in socket "A" for a really good price (low low low), fine. Note: [to my knowledge] only the socket "A" supports 32-bit ONLY CPU's (K7's).

--Doug

Markinoko
User offline. Last seen 6 years 46 weeks ago. Offline
Joined: 2006-04-09
Posts:

the Nforce/AMD combo seems fine also for me. if you want to go brute force, get an dual core AMD64 and compile your system accordingly ;-) that's my opinion though...

I'd like to take advantage of this topic to post something similar to what I posted on linuxsampler-devel about a project I might launch on the net in futur weeks.

Just a few words about this distribution I'm working on. it's called MLFS (because it's based on LFS, with a little more Music in it...) since it went better than I thought, I'm going to make it a collaborative project. I'll be glad to have anyone who wishes aboard ;-)

It is based on LFS ( http://www.linuxfromscratch.org ), so it is highly custumizable, and allows among other things to built interresting test platforms. ardour/general audio developpers/users may find it useful for tests issues as well as learning tool for advanced audio concepts on a linux system. It's nice also to be able to tweak things yourself, or as discussed here, to optimize for a specific architecture.

I'll post something around here when I get things started (the distribution is near ready and could reach beta stage soon, but some code cleanup is necessary before anything goes on the internet).

Marc-Olivier Barre,
Kinoko en Orbite