On 11 October 2012 at 9:07, Jeremy Jongepier <jeremy(a)autostatic.com> wrote:
On 10/11/2012 08:33 AM, Kevin Cosgrove wrote:
I've been trying to reduce my xrun troubles. I'm down from > 10
xruns per second to something more like 10 xruns per minute. Still
not good, but better.
I used the realTimeConfigQuickScan.pl script to diagnose things.
https://code.google.com/p/realtimeconfigquickscan/
I'm down to three things reported as "not good" now.
1. Checking checking sysctl inotify max_user_watches... < 524288 - not good
increase max_user_watches by adding 'fs.inotify.max_user_watches = 524288'
to /etc/sysctl.conf and rebooting
For more information, see
http://wiki.linuxmusicians.com/doku.php?id=system_configuration#sysctl.conf
Looking at the link there's a comment, "...it remains very
unclear ... if adjusting this value actually does anything at
all." So, I haven't altered this. Does anyone have
experience saying that this helped them?
Hello Kevin,
I've added this comment after having asked the exact same question at my
LAC2011 workshop. Nobody in the audience could acknowledge that changing
the inotify setting helped anything.
Nice to know.
2. chrt:
failed to set pid 0's policy: Operation not permitted
Checking the ability to prioritize processes with chrt... no - not good
Could not assign a 80 rtprio value. Set up limits.conf.
For more information, see
http://wiki.linuxmusicians.com/doku.php?id=system_configuration#limits.conf
I did make the changes outlined at the above link. I still
get the above report. I'm going to guess that I need some
real-time support from the kernel to make this work. Which
brings me to
3. Kernel with Real-Time Preemption... not found - not good
Kernel without real-time capabilities found
For more information, see
http://wiki.linuxmusicians.com/doku.php?id=system_configuration#installing_…
First I looked at this link:
http://wiki.linuxmusicians.com/doku.php?id=system_configuration#the_kernel
Specifically, I looked at the threadirqs kernel option.
grep -e CONFIG_IRQ_FORCED_THREADING=y -e CONFIG_PREEMPT=y /boot/config-`uname -r`
produces "CONFIG_IRQ_FORCED_THREADING=y" and I think that's good.
No it's not, unless it also outputs CONFIG_PREEMPT=y. if it doesn't than
your kernel isn't preemtible and in that case I doubt if threadirqs or
even chrt works (no expert on this).
A comment at the above link says, "If [the grep command]
returns CONFIG_IRQ_FORCED_THREADING=y and CONFIG_PREEMPT=y
then your kernel is using IRQ threading and you don't have
to proceed with the following steps. If it only returns
CONFIG_IRQ_FORCED_THREADING=y you can add the threadirqs boot
option as described..." My grep was in the 2nd case, with
only CONFIG_IRQ_FORCED_THREADING set to "y", so I proceeded
with the rest of the "threadirqs" instructions related to grub.
That didn't seem to work.
I altered
my /boot/grub2/grub.cfg file to include
"threadirqs" on the stanza for my kernel, like so, but
without all the line breaks.
linux /boot/vmlinuz-3.5.5-2.fc17.x86_64
root=UUID=77edf07a-a49b-48dd-82c8-2f9e5c8691b7 ro nomodeset
rd.md=0 rd.lvm=0 rd.dm=0 SYSFONT=True KEYTABLE=us rd.luks=0
LANG=en_US.UTF-8 rhgb quiet threadirqs nouveau.modeset=0
rd.driver.blacklist=nouveau
Slightly OT, but wow, that's a whole lot of kernel options ;) I only use
two or three.
I left all of that in there from Fedora's installation of the kernel.
Check if your kernel is preemtible (at least, I think
that might be a
probable cause) or install a kernel that is preemtible
# CONFIG_PREEMPT_RCU is not set
CONFIG_PREEMPT_NOTIFIERS=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
(there's no real-time kernel available for FC17?).
CCRMA has kernel-rt-3.4.11-1.rt19.2.fc17.ccrma.x86_64 but it
doesn't play nicely with my nVidia card and X config. I changed
the X config to use the nouveau driver, which got it to boot to
level 5 at least. But the geometry is not good and that driver
ignores my 2nd display. I found A LOT of potentially useful
information with a websearch for enabling an nVidia driver with a
CCRMA kernel. Sorting that out is a possibility.
Thanks....
--
Kevin