Ubuntu 8.10: rt kernel improved?

[Splashman]

Hi men:
ive got my intrepid ubuntu x64 working in real time with the generic kernel, (the non -rt pached). and i only have one little trouble. when i launch ardour after the jack controls, ardour advice me about a mem lock but i haven't
the message is:

Code: Select all

WARNING: Your system has a limit for maximum amount of locked memory. This might cause Ardour to run out of memory before your system runs out of memory. 

You can view the memory limit with 'ulimit -l', and it is normally controlled by /etc/security/limits.conf

and doing:

Code: Select all

ulimit-l
32

in that moment i have 85% of all resources freely with 2gb of ram and 1024 of swap.
Anybody know how control that mem lock¿?
thanks.

i almost got it

[raboof]

Code: Select all

You can view the memory limit with 'ulimit -l', and it is normally controlled by /etc/security/limits.conf

and doing:

Code: Select all

ulimit-l
32

Anybody know how control that mem lock¿?

32 is really quite small, I have it set to 500000. As the message says, you can set it in /etc/security/limits.conf, see also http://wiki.linuxmusicians.com/doku.php ... imits.conf

[Splashman]

it simply works now
my sound is almost ready
thank you very much!!

[raboof]

I did some benchmarking. I started vkeybd and kmidimon, attached them both directly and though 'midi though', and compared the arrival times of the 'direct' and the 'routed' event.

On the -rt kernel, the lag was usually 0 and sometimes 1. On -generic, it was usually 2 and sometimes 1 or 4 - so it looks like loopback midi isn't affected by the problem.

Then I tried routing the signal to my usb midisport. I physically connected 'out a' to 'in b' and observed the latencies. On the -generic kernel, it was again usually 2 and sometimes 1 or 4. On -rt, however, it ranged from 66 to 147!

So it looks like I have a nicely reproducable testcase here.

I wonder if this is an Ubuntu-specific problem: http://www.nabble.com/kernel-and-midi-s ... 43960.html

(I tried compilin an -rt kernel with CONFIG_X86_UP_IOAPIC enabled, but ran into all sorts of trouble similar to comment #36 at http://blog.avirtualhome.com/2008/10/28 ... -intrepid/ , so I'm giving that up for now)

[raboof]

I installed linux-image-2.6.29-1-multimedia-686 from the 64studio 3 beta (installed it from http://apt.64studio.com/backports/pool/ ... linux-2.6/ by adding "deb http://apt.64studio.com/backports hardy-backports main" to my sources.list .

Results are comparable to the ubuntu -rt kernel when using 'midi though' (e.g.: good) and comparable with the -generic when routing though the midisport (e.g.: also good/acceptable).

to rebuild the virtualbox drivers, i had to:
- get the kernel source
- unpack it
- run 'make prepare'
- edit Makefile to prevent mrproper from deleting stuff like version.h
- apply changes mentioned at http://forums.virtualbox.org/viewtopic.php?t=12854
- and then hit a brick wall because scripts/genksyms/genksyms isn't built yet. not sure how to create it.

[thorgal]

- and then hit a brick wall because scripts/genksyms/genksyms isn't built yet. not sure how to create it.

have you tried 'make scripts' ?

[raboof]

- and then hit a brick wall because scripts/genksyms/genksyms isn't built yet. not sure how to create it.

have you tried 'make scripts' ?

Ha, that indeed built it. Next I did:
- dkms build -m vboxdrv -v 2.0.4 --kernelsourcedir /usr/src/linux-source-2.6.29-studio64/
- dkms install -m vboxdrv -v 2.0.4 --kernelsourcedir /usr/src/linux-source-2.6.29-studio64/

Unfortunately modprobing the generated vboxdrv.ko yields 'Invalid module format' - dmesg mentions 'vboxdrv: no symbol version for struct_module'. Found http://ubuntuforums.org/showthread.php?t=972399 , but 64studio's /lib/modules/2.6.29-1-multimedia-686 doesn't have a Module.symvers. Another hint at http://linux.derkeiler.com/Mailing-List ... 08491.html

[raboof]

I did some benchmarking. I physically connected 'out a' to 'in b' and observed the latencies. On the -generic kernel, it was again usually 2 and sometimes 1 or 4. On -rt, however, it ranged from 66 to 147!

So it looks like I have a nicely reproducable testcase here.

I tried this benchmark again with 2.6.28-3-rt (from Jaunty, version 2.6.28-3.12), and the delays now seem reasonable.

[raboof]

I did some benchmarking. I physically connected 'out a' to 'in b' and observed the latencies. On the -generic kernel, it was again usually 2 and sometimes 1 or 4. On -rt, however, it ranged from 66 to 147!

So it looks like I have a nicely reproducable testcase here.

I tried this benchmark again with 2.6.28-3-rt (from Jaunty, version 2.6.28-3.12), and the delays now seem reasonable.

.. however, the 64studio kernel still performs *much* better.

With an otherwise identical configuration, starting pulseaudio with module-jack-sink, 2.6.28-3 from ubuntu immediately starts spitting out xruns, while 2.6.29-1-multimedia-686 from 64studio runs smoothly.

I guess it'd be nice to have a better benchmark for this.

[raboof]

I did some benchmarking. I physically connected 'out a' to 'in b' and observed the latencies. On the -generic kernel, it was again usually 2 and sometimes 1 or 4. On -rt, however, it ranged from 66 to 147!

So it looks like I have a nicely reproducable testcase here.

I tried this benchmark again with 2.6.28-3-rt (from Jaunty, version 2.6.28-3.12), and the delays now seem reasonable.

The standard 2.6.26 non-realtime kernel in debian testing also performs well in this test (delays typically between 2 and 5). Surprisingly good.

[spm_gl]

Can we make a "standardized" benchmark this way? I.e. a certain file, a certain jack setting (or a few) and a default player? I'd prefer command-line based too. No, not as a pissing contest, but rather to see if one's system performs to spec, and to see how different kernel/distribution/hardware combinations perform.
Oh, and some kind of dsp-stress-test would be nice too.

[raboof]

Can we make a "standardized" benchmark this way? I.e. a certain file, a certain jack setting (or a few) and a default player? I'd prefer command-line based too. to see if one's system performs to spec, and to see how different kernel/distribution/hardware combinations perform.
Oh, and some kind of dsp-stress-test would be nice too.

I'd certainly be interested in good, easy-to-run audio benchmarking tools to find out which parts of the machine deserve more tuning (or better hardware).

I could make the above test a bit easier to reproduce, but it does require a bit of hardware (the midi loopback), as it's basically a way of measuring the overhead of the usb midi thing .

[spm_gl]

For audio benchmarking, all it really takes is a few sound files (16/44.1, 24/48, 24/96), alsaplayer, jack, and some dsp-hungry plugin that can be launched from the console. Then we can write a script that looks for x-runs to get a basic system measurement, and launch as many instances of the plugin as possible.
A short pulse through an audio loop can measure true delay time (makes no sense with plugin enabled though).