[LAU] Realtime, but many xruns when jack is started. Debian Etch

[Nigel Henry]

On Wednesday 03 October 2007 15:05, Florian Schmidt wrote:
> On Wednesday 03 October 2007, Wolfgang Woehl wrote:
> > Montag, 1. Oktober 2007 Marcos Guglielmetti:
> > > @audio     -    rtprio   99
> > > @audio     -    nice      -10
> > > @audio     -    memlock     4000000
> >
> > Marcos, looking at these numbers (and variations of these on various
> > netpages) I always wonder whether they are such a good idea: Wouldn't
> > rtprio 99 allow for banzai processes to almost lock down the machine?
> > Wouldn't memlock 4000000 (4GB) be like begging for a swapfest on standard
> > 1GB/2GB machines? Isn't the whole point about limits.conf to effectively
> > prevent processes from sucking in all resources? So that when realtime
> > processes go havoc you'll be left with cycles and memory to survive the
> > situation?
>
> Yes,
>
> one always assumes with settings like this, that the programs which are run
> are nicely behaved (e.g. jackd has a watchdog to kill its clients when they
> run havok)..
>
> But whether you give one process RT prio 1 or 99 doesn't matter. It can
> always keep all SCHED_OTHER threads [the rest of your system, X, xterms,
> whatnot] from running at all effectively freezing the box (though in
> reality this is expected behaviout).
>
> A typical method to counter this scenario would be to limit user processes
> to prio 98 and have another watchdog process runnning at prio 99. That
> watchdog would have another thread running at SCHED_OTHER and checks at
> regular intervals whether this thread got to run at all. If not -> take
> action and make e.g. all SCHED_FIFO threads in the system SCHED_OTHER so
> the user is able to recover from the situation.. There are several
> watchdogs available (including one from yours truly which needs an overhaul
> though)..
>
> And yes, of course, you wouldn't want to give all system memory away to
> mlocking. You need some reserve..
>
> Nice -10 otoh is pretty uncritical i guess.
>
> Regards,
> FLo

I started this thread, but at the moment I'm not having much success at 
getting realtime to work on Debian Etch, and that's before I start on Lenny.

Realtime works fine on Fedora 7, using the realtime low latency kernel from 
planetccrma, plus rtirq, and a pam update from planetccrma that gave me a 
limits.conf.rpmnew file, as below.

# limit realtime and memory locking access to users in the group audio
# there is no way to say "allow locking all memory", 4G should be enough
#
#*  - rtprio  0
#*  - nice  0
#
#@audio  - rtprio  99
#@audio  - nice  -10
#@audio  - memlock  4000000

# or (default) allow everyone access
*  - rtprio  99
*  - nice  -10
*  - memlock  4000000

Editing the existing limits.conf, adding the above, and commenting out the 
default entries for jack, works fine. When starting jackd in qjackctl, I'm 
getting one xrun every 6m 25secs on average, and the largest xrun over the 
time I tested was about 0.325 msecs. I tested over about 2 1/2 hours, and the 
only other apps open on the desktop were Xawtv, and Gkrellm.

On Debian Etch, after adding Marcos's repo to /atc/apt.sources.list, I 
installed the 2.6.21-rt4, and 2.5.21.5-rt18 kernel, along with rtirq version 
20070101. I edited limits.conf, and added the part above that I received from 
planetccrma. That didn't work, with xruns every 2-3secs. I commented out the 
default uncommented lines, and uncommented the audio lines, which are at the 
top of this post. Still I get xruns every 2-3 secs, and if I reboot and try a 
non rt kernel, xruns every 2-3 secs again. It appears that there is still 
something missing to get realtime working on Etch.

I may have to download Musix again, and see how realtime runs on it. I DL'd 
before, but that was when there was a problem with it booting with some 
hardware. As I'm on dialup, I'd put off DL'ing it again, since the booting 
problem has been resolved.

Marcos. If your reading this. Could you provide the link to download Musix 
again please.

Thanks for all the replies to this thread.

Nigel.