7 Aug
2008
7 Aug
'08
9:52 p.m.
I got rid of
rtirq and das-watchdog entirely. after that, the machine
didn't
lock up for at least as long as Robins session,
~45 mins, but the in the
middle of some session I would have liked to keep the recording of,
dang..
sorry, but without rtirq the whole thing is useless.
8 Aug
8 Aug
4:56 a.m.
I did test with a few other versions of config, patchset and kernel sources
but keep running into problems. I can't seem to be able to produce something
that works reliably, all of the kernels run around 30 to 45 minutes with
around 65 - 70% load on jackd and then hard lock. Since this machine I am
using is pretty new, and I am havn't really run rt-linux on this one
extensivly yet (partly because its almost not necessary with current stock
debian kernels anymore), it could be something about the hardware, although
it seems unlikely. Its a T61 T5500 with 1G Ram fwiw. With this in mind I
think I should ask for some advice on what people consider sane values for
important scripts, pam etc. My /etc/security/limits.conf looks like this:
@audio - rtprio 99
@audio - nice -15
@audio - memlock 1024000000
What values do people use, and why? Are these sane values? I remember that
realtime-lsm did something more brutal than this, so I would find it hard to
see how this could be the reason. What are the rtirq settings that are
considered safe? For now, I switched it off, yet I can see how it could be
useful/necessary for certain setups, and don't want to rule it out
completely. I start jackd oh hw:1 (hdsp multiface) with the following
parameters:
/usr/bin/jackd -R -P89 -m -dalsa -dhw:1 -r48000 -p128 -n2 -Xseq
This works really well with SuperCollider 3 doing quite a lot of
synthesis... well... until it locks up the machine. Could it be the
Interrupt-sharing particular to my machine? I see that yenta sits on an
interrupt together with uhci (usb?) and my graphics card (Intel graphics
chipset DRM). Do people tend to switch ACPI off anymore, like it is being
recommended for certain setups on the RT-wiki?
Last, but not least: my version of gcc is 4.3.1-2 (Debian). I briefly
thought this could be the source of the problem, but obviously have hardly a
way to test that, except for building a kernel on a different OS. hmmmmm,
I'm getting frustrated with this, need some advice and success to keep me
going.... :)
bbfn
karsten
5:04 a.m.
one or 2 quick addedums:
ubuntu hardy kernel works great for me. it is presumably compiled with a
different version of gcc, 4.2.3. could this be the source of the problems?
On Thu, Aug 7, 2008 at 11:56 PM, krgn <k.gebbert(a)gmail.com> wrote:
I did test with a few other versions of config,
patchset and kernel sources
but keep running into problems. I can't seem to be able to produce something
that works reliably, all of the kernels run around 30 to 45 minutes with
around 65 - 70% load on jackd and then hard lock. Since this machine I am
using is pretty new, and I am havn't really run rt-linux on this one
extensivly yet (partly because its almost not necessary with current stock
debian kernels anymore), it could be something about the hardware, although
it seems unlikely. Its a T61 T5500 with 1G Ram fwiw. With this in mind I
think I should ask for some advice on what people consider sane values for
important scripts, pam etc. My /etc/security/limits.conf looks like this:
@audio - rtprio 99
@audio - nice -15
@audio - memlock 1024000000
What values do people use, and why? Are these sane values? I remember that
realtime-lsm did something more brutal than this, so I would find it hard to
see how this could be the reason. What are the rtirq settings that are
considered safe? For now, I switched it off, yet I can see how it could be
useful/necessary for certain setups, and don't want to rule it out
completely. I start jackd oh hw:1 (hdsp multiface) with the following
parameters:
/usr/bin/jackd -R -P89 -m -dalsa -dhw:1 -r48000 -p128 -n2 -Xseq
This works really well with SuperCollider 3 doing quite a lot of
synthesis... well... until it locks up the machine. Could it be the
Interrupt-sharing particular to my machine? I see that yenta sits on an
interrupt together with uhci (usb?) and my graphics card (Intel graphics
chipset DRM). Do people tend to switch ACPI off anymore, like it is being
recommended for certain setups on the RT-wiki?
Last, but not least: my version of gcc is 4.3.1-2 (Debian). I briefly
thought this could be the source of the problem, but obviously have hardly a
way to test that, except for building a kernel on a different OS. hmmmmm,
I'm getting frustrated with this, need some advice and success to keep me
going.... :)
bbfn
karsten
5:11 a.m.
On Fri, Aug 8, 2008 at 12:04 AM, krgn <k.gebbert(a)gmail.com> wrote:
one or 2 quick addedums:
ubuntu hardy kernel works great for me. it is presumably compiled with a
different version of gcc, 4.2.3. could this be the source of the problems?
oops, I sent too early: one thing I will test is to compile the exact
version of ubuntu kernel with same config on my machine and run it - if it
hard locks that I'll look into how to change the default compiler and try to
compile the other kernels with that, just to rule this out as a source for
problems.
http://www.mail-archive.com/debian-kernel@lists.debian.org/msg32314.html
8:59 a.m.
krgn said :
On Fri, Aug 8, 2008 at 12:04 AM, krgn
<k.gebbert(a)gmail.com> wrote:
Yes I was going to suggest that, if you think your system is the source
of the problem and generates bogus binaries, then get the deb source of
the ubuntu rt kernel and compile it locally. (don;t forget to apply the
patches).
On the config side,
one thing to check as well, is the default ARCH that the kernel is
compiled for, all the p:d style kernel config are set to PIII, I would
imagine a generic Ubuntu kernel is just plain Pentium.
a.
one or 2 quick addedums:
ubuntu hardy kernel works great for me. it is presumably compiled with a
different version of gcc, 4.2.3. could this be the source of the problems?
oops, I sent too early: one thing I will test is to compile the exact
version of ubuntu kernel with same config on my machine and run it - if it
hard locks that I'll look into how to change the default compiler and try to
compile the other kernels with that, just to rule this out as a source for
problems. _______________________________________________
Linux-audio-tuning mailing list
Linux-audio-tuning(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-tuning
11:59 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
aymeric mansoux wrote:
krgn said :
I get the same freezes
with CONFIG_MCORE2=y CONFIG_X86_GENERIC=n
and CONFIG_M586=y CONFIG_X86_GENERIC=y
and CONFIG_MPENTIUMIII=y CONFIG_X86_GENERIC=y (-krgn)
You guys are way ahead! I was going to suggest cherry-picking
git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-linux.git
Which exhibits the same problem.
Collecting patches probably yields a distributable binary in shorter time.
I'll look into DNS for git.linuxaudio.org and we should discuss
collaborative work-flow in a different thread.
just brainstorming: would sth along the lines of
http://fate.multimedia.cx/ be feasible for rt-linux? - well, the
"tests-passed" is obviously crazy to implement. But a "per compiler"
"per ARCH" public stderr is definitely nifty. and I'd be surprised if
there is no such system yet ;) - it's hard to keep track these days..
While I do know my way around, I'm not a kernel hacker.
robin
On Fri, Aug 8, 2008 at 12:04 AM, krgn
<k.gebbert(a)gmail.com> wrote:
Yes I was going to suggest that, if you think your system is the source
of the problem and generates bogus binaries, then get the deb source of
the ubuntu rt kernel and compile it locally. (don;t forget to apply the
patches).
On the config side,
one thing to check as well, is the default ARCH that the kernel is
compiled for, all the p:d style kernel config are set to PIII, I would
imagine a generic Ubuntu kernel is just plain Pentium.
one or 2 quick addedums:
ubuntu hardy kernel works great for me. it is presumably compiled with a
different version of gcc, 4.2.3. could this be the source of the problems?
oops, I sent too early: one thing I will test is to compile the exact
version of ubuntu kernel with same config on my machine and run it - if it
hard locks that I'll look into how to change the default compiler and try to
compile the other kernels with that, just to rule this out as a source for
problems. -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkicUR4ACgkQeVUk8U+VK0KTSwCgvycqN0KoCENOoCdC7wkJTh0B
Q9wAniHLsaptQBiAVJLR499evCzeJ4Qc
=BYiM
-----END PGP SIGNATURE-----
12:08 p.m.
Hi Robin,
I'll look into DNS for git.linuxaudio.org
Taken care of, should be working later today.
Cheers!
Daniel
12:06 p.m.
New subject: rtlimits (was: a working rt-kernel -- please test )
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
krgn wrote:
one or 2 quick addedums:
ubuntu hardy kernel works great for me. it is presumably compiled with a
different version of gcc, 4.2.3. could this be the source of the problems?
maybe, maybe not. it depends on compiler flags. That may be a question
for gcc specialists on the linux-rt-user mailing list.
I start to think we're chasing two independent but related bugs:
/something/ inside the kernel is triggered by invalid user setup. eg.
RT-priority inversion.
On Thu, Aug 7, 2008 at 11:56 PM, krgn
<k.gebbert(a)gmail.com> wrote:
> I did test with a few other versions of config, patchset and kernel sources
> but keep running into problems. I can't seem to be able to produce something
> that works reliably, all of the kernels run around 30 to 45 minutes with
> around 65 - 70% load on jackd and then hard lock. Since this machine I am
> using is pretty new, and I am havn't really run rt-linux on this one
> extensivly yet (partly because its almost not necessary with current stock
> debian kernels anymore), it could be something about the hardware, although
> it seems unlikely. Its a T61 T5500 with 1G Ram fwiw. With this in mind I
> think I should ask for some advice on what people consider sane values for
> important scripts, pam etc. My /etc/security/limits.conf looks like this:
>
> @audio - rtprio 99
> @audio - nice -15
> @audio - memlock 1024000000
i use
@audio - rtprio 90
@audio - nice -5
@audio - memlock 1400000
The man page says memlock's unit is KB not bytes.
IIRC someone said it's actually pages, but I did not check the source.
> What values do people use, and why? Are these sane
values?
I think so.
rtprio ranges from 1 to 99 and it does not matter how big the difference
is; as long as a value is larger it will "win" against lower values -
for SCHED_FIFO that is. - many suggest to leave a little "headroom"; it
does not need to be 99.
> What are the rtirq settings that are
> considered safe?
100 > timer-prio > sound-card-prio > jackd-process prio > 0
with a UA-25 on USB I use:
rtirq: reset [softirq-timer] pid=6 prio=1: OK.
rtirq: reset [softirq-timer] pid=11161 prio=1: OK.
rtirq: start [softirq-timer] pid=6 prio=99: OK.
rtirq: start [softirq-timer] pid=11161 prio=99: OK.
rtirq: start [rtc] irq=8 pid=2397 prio=90: OK.
rtirq: start [uhci_hcd:usb3] irq=22 pid=1066 prio=89: OK.
rtirq: start [i8042] irq=1 pid=330 prio=87: OK.
rtirq: start [i8042] irq=12 pid=329 prio=86: OK.
and run /usr/bin/jackd -R -P70 ...
<bit-off-topic>
@audio /usr/bin/jackd nice=-1 rtprio=85
@audio /usr/bin/qjackctl nice=-1 rtprio=84
@audio /usr/bin/ardour nice=-1 rtprio=83
@audio /usr/bin/hydrogen nice=-1 rtprio=82
as found on
http://proaudio.tuxfamily.org/wiki/index.php?title=Howto_RT_Kernel
is IMHO nonsense - in fact wrong: ONLY the jack-realtime callback should
have elevated priority. The audio-process-callback of the applications
will inherit this priority.
The above example would prefer GUI or JACK-stdio/log over disk-I/O.
There are use-cases where you may want to give an older-RTC-based
MIDI-application realtime priority. JACK-midi solves that for good.
</bit-off-topic>
> For now, I switched it off,
makes sense to debug&trace.
> yet I can see how it could be
> useful/necessary for certain setups, and don't want to rule it out
> completely. I start jackd oh hw:1 (hdsp multiface) with the following
> parameters:
>
> /usr/bin/jackd -R -P89 -m -dalsa -dhw:1 -r48000 -p128 -n2 -Xseq
now it clicked in the back of my head: there was something like
subtracting or adding 10 from the rt-priority in qjackctl, or jackd.
just a shot in the dark: jackd itself starts a couple of threads with
different priorities. I never cared since it just worked (and still does
on 2.6.24-rt3). - later today I'll be looking at jackd.
Meanwhile, does anyone here know about changes in the scheduler,
priority inversion etc of 2.6.26 ?
For high-level tests it may be interesting if a 2.6.26-rtX would run
stable if it does not do any audio or RT at all - just to double-back.
same without ACPI. for all we know this could well be caused by the
keyboard or some tty driver, no? I wish I had more machines to test ;)
puh, sorry for another long email - i got carried away.
robin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkicUs4ACgkQeVUk8U+VK0LcGwCgwR6VIOLUN7YUGvS/0vEPpn+Q
PNkAnR+c2CeekQUK89S65FTtIeAqB1BU
=ZidW
-----END PGP SIGNATURE-----
11:39 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
krgn wrote:
>> I got rid of rtirq and das-watchdog entirely.
after that, the machine
> didn't
>> lock up for at least as long as Robins session, ~45 mins, but the in the
>> middle of some session I would have liked to keep the recording of,
> dang..
>
> sorry, but without rtirq the whole thing is useless.
I should have said: without rtirq the setup is not really usable for
professional sound-production or live-performance, but handy nonetheless.
really? how so?
because you can not guarantee
that soundcard I/O is handled in time.
you might just as well run a lowlatency kernel without RT.
I mean I can understand what it doesn, but I
personally
havn't seen it doing anything significant for i/o performance.
The general I/O performance may even go down; since fi. the sound-card
would be allowed to /interrupt/ network-i/o. - In >99% of cases the
system will run without RTirq as it will with RTirq.
If we reach a more stable 2.6.26-rt - we should ask the PPL on
ardour-users ; some of them do 64 or 128 audio-channels and you will
definitely experience a difference there.
that said, I
don't really do latencies lower than 128 samples... let me know your
view/experiences/hints.
heh, hints are hard to come by.
most of the time I run at 64 * 3 (for recording) and 1024 or 2048 (for
mastering); mobile via USB, if I need more channels via 1394. The
build-in HDA on this TP-X60s does only "work" at 128, 1024 and up, but
that's OT; i mostly use it only as "phone". - I use max. 10
hardware-channels, but occasionally go above 256 jack ports.
I never succeeded to get a Xrun free setup without rtIRQ - but the hdsp
multiface PCI/PCMCIA interface may be more /forgiving/ that the USB or
firewire stack.
2c,
robin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkicTHAACgkQeVUk8U+VK0Kq7ACgwnb1D/ACAQakJKnhTuwi9/7M
K0wAn2DXYYt4/b7yVhh6oJAGPYDkJGua
=d6+j
-----END PGP SIGNATURE-----
5905
days inactive
5906
days old
linux-audio-tuning@lists.linuxaudio.org
8 comments
4 participants
participants (4)
-
aymeric mansoux -
Daniel James -
krgn -
Robin Gareus