2 Aug
2004
2 Aug
'04
7:56 p.m.
I've not been able to follow LKML too closely in the last few weeks, so
i'm out of loop with the recent developments. If some of you folks did
watch it, do you care to bring the rest of us up to speed WRT the latest
2.6 developments that are related to "audio" kernels? The issues i'm
interested in are:
1. "Classic" pre-emptability. Why Con Kolivas recommends against
enabling preempt in vanilla 2.6, and (if it was a valid recommendation)
whether that is still an issue
2. The Ingo Molnar voluntary preempt patches. Are they ready yet,
yes/no? With or without -mm?
3. Staircase scheduler, either as a standalone thing or incorporated in
the latest -mm patch. Better than vanilla for audio, yes/no?
4. Combinations of the above. Is the classic preemt compatible with the
rest? Anyone using the "vanilla preempt + Ingo Molnar patches + Andrew
Morton series + staircase" supercombo?
--
Florin Andrei
http://florin.myip.org/
2 Aug
2 Aug
8:31 p.m.
Quoting Florin Andrei <florin(a)andrei.myip.org>rg>:
I've not been able to follow LKML too closely in
the last few weeks, so
i'm out of loop with the recent developments. If some of you folks did
watch it, do you care to bring the rest of us up to speed WRT the latest
2.6 developments that are related to "audio" kernels?
I guess this boils down to how you want to spend your time.
You can either use your audio tools to compose and create music... or ...
you can spend your days compiling kernels and "fixing" problems which aren't
broken.
It's interesting to note how little time my Pro Tools friends spend on their
Operating System [the "primitive" MacOS 8.6] compared to actually using
their audio tools. :) Of course, I know this is LINUX-audio, and the Linux
part comes before audio, so therefore it gets more attention than actually
making noises through the speakers. ;)
I have not followed the bleeding edge, but 2.6+preempt+patches have not
given the rock-solidly reliable low latency of 2.4.26-preempt which has a
nice and predictable testing record.
I'm sure with enough time and effort you might get 2.6 "back" to 2.4 levels,
but it's all changing a great deal right now. Give it at least another
month to settle down and for all of the changes to be tested and whatnot.
Please take Linux oldtimers' advice: the maturity of new Linux kernels
approximately matches humans: up through the teens are very stormy and often
deadly - once they've killed themselves off, things are safe enough to start
to use. :)
=MB=
--
A focus on Quality.
11:38 p.m.
On Mon, 2004-08-02 at 15:15, Malcolm Baldridge wrote:
Quoting Florin Andrei <florin(a)andrei.myip.org>rg>:
Actually, i'll need 2.6 _and_ some serious low-lat capabilities for
another, non-musical, "real world" application (read: making money out
of it - not that people can't make money out of music, i'm just speaking
for myself). 2.4 won't work there.
But it wouldn't hurt to get it going on my multimedia workstation too,
so i guess it's a matter of hitting two birds with one stone, which is a
good thing... if it works. ;-)
I've not been able to follow LKML too closely
in the last few weeks, so
i'm out of loop with the recent developments. If some of you folks did
watch it, do you care to bring the rest of us up to speed WRT the latest
2.6 developments that are related to "audio" kernels?
I guess this boils down to how you want to spend your time.
You can either use your audio tools to compose and create music... or ...
you can spend your days compiling kernels and "fixing" problems which
aren't
broken. It's interesting to note how little time my Pro
Tools friends spend on their
Operating System [the "primitive" MacOS 8.6] compared to actually using
their audio tools. :) Of course, I know this is LINUX-audio, and the Linux
part comes before audio, so therefore it gets more attention than actually
making noises through the speakers. ;)
I hear you.
The thought of migrating to Mac crosses my mind every now and then, but
gets chased away quickly. :-)
--
Florin Andrei
http://florin.myip.org/
11:52 p.m.
It's interesting to note how little time my
Pro Tools friends spend on their
Operating System [the "primitive" MacOS 8.6] compared to actually using
their audio tools. :) Of course, I know this is LINUX-audio, and the Linux
part comes before audio, so therefore it gets more attention than actually
making noises through the speakers. ;)
I hear you.
The thought of migrating to Mac crosses my mind every now and then, but
gets chased away quickly. :-) 
3 Aug
3 Aug
11:42 a.m.
Florin Andrei wrote:
Nahh...I'm writing you from my Gentoo laptop - a Compaq Presario 3GHz
machine. It runs Alsa. (Well, sort of as the sound chip driver is once
again broken, so it runs it when I go back to an older 2.6.6 kernel.)
However, and back on point, the machine is dual-boot running Win XP Pro
and Pro Tools with an 002 Rack. I use an external 1394 drive for audio.
I really spend very little time worrying about the XP OS, but far more
time worrying about viruses.
Just go dual boot and get the best of both worlds. I'm sure one day
Linux will make a bigger impact than today for many of us. It's just not
reliable enough in the audio area for me to depend on it much, but it
sure is fun. (Well, so's XP since I can play more games...)
- Mark
On Mon, 2004-08-02 at 15:15, Malcolm Baldridge wrote:
<SNIP>
It's
interesting to note how little time my Pro Tools friends spend on their
Operating System [the "primitive" MacOS 8.6] compared to actually using
their audio tools. :) Of course, I know this is LINUX-audio, and the Linux
part comes before audio, so therefore it gets more attention than actually
making noises through the speakers. ;)
I hear you.
The thought of migrating to Mac crosses my mind every now and then, but
gets chased away quickly. :-)
2 Aug
2 Aug
10:03 p.m.
On Mon, 02 Aug 2004 14:40:37 -0700
Florin Andrei <florin(a)andrei.myip.org> wrote:
I've not been able to follow LKML too closely in
the last few weeks,
so i'm out of loop with the recent developments. If some of you folks
did watch it, do you care to bring the rest of us up to speed WRT the
latest 2.6 developments that are related to "audio" kernels? The
issues i'm interested in are:
1. "Classic" pre-emptability. Why Con Kolivas recommends against
enabling preempt in vanilla 2.6, and (if it was a valid
recommendation) whether that is still an issue
2. The Ingo Molnar voluntary preempt patches. Are they ready yet,
yes/no? With or without -mm?
3. Staircase scheduler, either as a standalone thing or incorporated
in the latest -mm patch. Better than vanilla for audio, yes/no?
4. Combinations of the above. Is the classic preemt compatible with
the rest? Anyone using the "vanilla preempt + Ingo Molnar patches +
Andrew Morton series + staircase" supercombo?
Hi, while i cannot give detailed answers to your questions i might chime
in with some general observations i made..
There are still unsolved issues with NPTL and jackd. Since 2.6.x has the
infrastructure to use NPTL [as opposed to unpatched 2.4.x] you will
stumble over these issues. The "fix" to export LD_ASSUME_KERNEL=2.4.19
[which makes libc use linuxthreads and not NPTL] seems to help with
these issues though. But as long as the problem isn't fully understood,
noone can say if there aren't any other potential issues with this.
2.6.x vanilla, with preempt enabled yields usable performance for hd
recording and other work. It is not sufficicent for real low latency
work, since although most of the kernel is preemptable, several very
important parts are not.. I can use 2*512 frames with jack alright in a
vanilla 2.6.x with RT jackd and the LD_ASSUME_KERNEL fix. But i don't
get
rocksolid-compile-a-kernel-at-the-same-time-and-still-get-no-xruns-perf
ormance as i did in 2.4.x+preempt+ll..
I once tried the staircase scheduler on a vanilla 2.6.x with preempt [i
think i applied the ck-patch directly to it, but it's been a while].
Since the staircase scheduler is only used for SCHED_OTHER threads, an
RT'ed jackd's performance will not differ substantially to a kernel with
the default O(1) scheduler. SCHED_FIFO threads are in a completely
different scheduling class which always gets cpu before any SCHED_OTHER
stuff..
Ingos volountary preemption stuff on the other hand does improve the
situation somewhat. I can use jackd and jackd-rack at 2*256 pretty
reliably.. 2*128 is ok, too, if you don't care about the occasional
xrun.
Right now i use 2.6.8-rc2-M5 and it looks good. The threaded IRQ handler
stuff by Ingo looks exciting, too. Afaik this makes all threaded irq
handlers fully preemptible, but i'm not sure about this. I'm also not
not sure whether i see real improvements. The irq handlers all run at
priority -51. I have jackd running with prio -75 [so it should be
scheduled before the prio=-51 irq threads] and i have my soundcard irq
handler set to non threaded.. I will watch this over the next days or
will try O2 maybe tonight..
I think that this is the right mooment to grab a vanilla 2.6.8-rc2 and
just try one of Ingos new volountary preemption patches. You might be
positively surprised.. If not, send a report to Ingo. Lee Revel is also
busy testing Ingos patches and reporting all latencies he found. But
more testers are needed.
--
Palimm Palimm!
http://affenbande.org/~tapas/
7 Aug
7 Aug
3:40 a.m.
On Mon, 2004-08-02 at 19:57, Florian Schmidt wrote:
I think that this is the right mooment to grab a
vanilla 2.6.8-rc2 and
just try one of Ingos new volountary preemption patches. You might be
positively surprised.. If not, send a report to Ingo. Lee Revel is also
busy testing Ingos patches and reporting all latencies he found. But
more testers are needed.
Hey,
I would have commented earlier but was out of town all week.
As Ingo's patches stabilize, it is very important for more people to
test them. With 2.6.8+voluntary-preempt-O3, using voluntary_preempt=3,
kernel_preemption=1, and the soundcard and RTC irqs non-threaded, it
works for me (tm) - I have been unable to produce a latency over 50
usecs, even while punishing the machine with parallel builds and iozone
-a.
We need people to test with different hardware configurations and
workloads. Especially needed are testers with ACPI, APIC, SMP, HT
machines. There are still some ACPI related bugs, more testers are
needed to nail these down. There are some reports of lockups which I
cannot reproduce.
I would not recommend any patches other than the stock kernel or -mm
kernel + the latest voluntary-preempt patches, just to simplify things.
Here are some of my test results using 2.6.8-mm2 + voluntary-preempt
O3. I have found the mm series provide about 10-20% better latency, but
I have had a few lockups that did not happen with the stock kernel; this
is the expected behavior for a development vs. stable kernel.
I should point out that we are operating very close to the limits of the
hardware - the difference between 45 and 55 usecs. This is at least an
order of magnitude BETTER than 2.4 + ll and closer to RTLinux than
anything else.
http://www.members.dca.net/rlrevell/testresults/test1.png
http://www.members.dca.net/rlrevell/testresults/test2.png
http://www.members.dca.net/rlrevell/testresults/test3.png
My test relies on some patches to jackd that I posted to the
jackit-devel mailing list. If anyone would like help getting a test
environment up and running please let me know.
Some real world testing with actual audio apps would be useful, since my
tests measure scheduling latency using a jack setup with no clients.
Lee
3:58 a.m.
On Fri, 2004-08-06 at 22:24, Lee Revell wrote:
On Mon, 2004-08-02 at 19:57, Florian Schmidt wrote:
That would be my laptop, probably :-)
I think that this is the right mooment to grab a
vanilla 2.6.8-rc2 and
just try one of Ingos new volountary preemption patches. You might be
positively surprised.. If not, send a report to Ingo. Lee Revel is also
busy testing Ingos patches and reporting all latencies he found. But
more testers are needed.
Hey,
I would have commented earlier but was out of town all week.
As Ingo's patches stabilize, it is very important for more people to
test them. With 2.6.8+voluntary-preempt-O3, using voluntary_preempt=3,
kernel_preemption=1, and the soundcard and RTC irqs non-threaded, it
works for me (tm) - I have been unable to produce a latency over 50
usecs, even while punishing the machine with parallel builds and iozone
-a.
We need people to test with different hardware configurations and
workloads. Especially needed are testers with ACPI, APIC, SMP, HT
machines. There are still some ACPI related bugs, more testers are
needed to nail these down. There are some reports of lockups which I
cannot reproduce.
I'm starting to test 2.6.7 rc2-mm2 + voluntary preempt O3 (at Planet
CCRMA). So far my limited tests have been very promising. I still have
to build a debugging version of alsa (and probably add your patches to
jack - very nice histograms!).
Hopefully I'll be able to contribute some data...
While I see a much decreased latency I still have weird problems with
jack and the combinartion of qjackctl, jack, several jack clients
loading the system, 2.6.x and nptl.
Many thanks for the work you have been doing! (I've been in a trip and
then too busy but was trying to monitor email and was looking at all
those posts without having time to test anything :-)
-- Fernando
4:42 a.m.
On Sat, 2004-08-07 at 01:43, Fernando Pablo Lopez-Lezcano wrote:
While I see a much decreased latency I still have
weird problems with
jack and the combinartion of qjackctl, jack, several jack clients
loading the system, 2.6.x and nptl.
There is almost definitely a bug in this area, but no one has been able
to reliably reproduce it. The issue is something like "clients don't
always get SCHED_FIFO with certain NPTL versions".
This was never too much of a problem because with 2.6 the latency wasn't
good enough anyway. Now that the 2.6 latency issues are resolved, it
would be very useful to track this bug down.
Lee
8:30 a.m.
On Sat, 07 Aug 2004 02:27:22 -0400
Lee Revell <rlrevell(a)joe-job.com> wrote:
There is almost definitely a bug in this area, but no
one has been
able to reliably reproduce it. The issue is something like "clients
don't always get SCHED_FIFO with certain NPTL versions".
This was never too much of a problem because with 2.6 the latency
wasn't good enough anyway. Now that the 2.6 latency issues are
resolved, it would be very useful to track this bug down.
Hi,
do you know how, in the case of volountary preemption and threaded irq
handlers, the irq's used by X11 are handled? i removed the nvidia module
from my kernelvand rebooted to have it untainted, but of course the X11
nv module does neither report to /proc/interrupts nor /proc/irq. SInce
it is on another bus [agp] i suppose this is no problem but i always
wondered about the interplay of the kernel an X. It looks to me like an
area which might still have some surprises..
Flo
--
Palimm Palimm!
http://affenbande.org/~tapas/
8:45 p.m.
On Sat, 2004-08-07 at 06:24, Florian Schmidt wrote:
do you know how, in the case of volountary preemption and threaded irq
handlers, the irq's used by X11 are handled? i removed the nvidia module
from my kernelvand rebooted to have it untainted, but of course the X11
nv module does neither report to /proc/interrupts nor /proc/irq. SInce
it is on another bus [agp] i suppose this is no problem but i always
wondered about the interplay of the kernel an X. It looks to me like an
area which might still have some surprises..
I believe that video cards use interrupts for 3d engine completion - you
tell the card to render such and such, rotate 30 degrees, zoom, and you
get an interrupt when it's done and ready for the next command.
There are certainly some surprises in this area. If 2D acceleration is
enabled on my onboard Via CLE266 video, the 2D engine will cause
interrupts from the PCI slot to be disabled for long periods. I am not
sure yet if this a bug or a feature.
I recommend disabling all hardware video acceleration when tuning a
system for low latency (set Option "NoAccel" and commend out the "dri"
line). This will prevent X from interacting directly with your hardware
- it is complicated enough when only the kernel can access hardware.
Then, once you get that working, re-enable 2D acceleration, then DRI/3D
acceleration, if these do not cause problems. This will make it much
easier to get the problematic video drivers fixed.
Lee
9:06 p.m.
On Saturday 07 August 2004 06:30 pm, Lee Revell wrote:
On Sat, 2004-08-07 at 06:24, Florian Schmidt wrote:
Tweaking the PCI latency timer values makes a big difference WRT the video
card hogging the buss. I know thats not what you're talking about per se, but
it's apropos WRT xruns/performance.
do you know how, in the case of volountary
preemption and threaded irq
handlers, the irq's used by X11 are handled? i removed the nvidia module
from my kernelvand rebooted to have it untainted, but of course the X11
nv module does neither report to /proc/interrupts nor /proc/irq. SInce
it is on another bus [agp] i suppose this is no problem but i always
wondered about the interplay of the kernel an X. It looks to me like an
area which might still have some surprises..
I believe that video cards use interrupts for 3d engine completion - you
tell the card to render such and such, rotate 30 degrees, zoom, and you
get an interrupt when it's done and ready for the next command.
There are certainly some surprises in this area. If 2D acceleration is
enabled on my onboard Via CLE266 video, the 2D engine will cause
interrupts from the PCI slot to be disabled for long periods. I am not
sure yet if this a bug or a feature.
I recommend disabling all hardware video acceleration
when tuning a
system for low latency (set Option "NoAccel" and commend out the
"dri"
line). This will prevent X from interacting directly with your hardware
- it is complicated enough when only the kernel can access hardware.
Then, once you get that working, re-enable 2D acceleration, then DRI/3D
acceleration, if these do not cause problems. This will make it much
easier to get the problematic video drivers fixed.
Lee
Definitely a good strategy, but nobody is going to take a system with no
video acceleration seriously.
9:32 p.m.
On Sat, 2004-08-07 at 18:50, John Check wrote:
Yes, of course this is not a long term solution. The point is to get
the buggy video drivers fixed (this is open source after all), in order
to do that we need to be able to say 'when i enable DRI with $FOO
driver, I get xruns, and these go away when I disable it'.
Lee
On Saturday 07 August 2004 06:30 pm, Lee Revell wrote:
I recommend
disabling all hardware video acceleration when tuning a
system for low latency (set Option "NoAccel" and commend out the
"dri"
line). This will prevent X from interacting directly with your hardware
- it is complicated enough when only the kernel can access hardware.
Then, once you get that working, re-enable 2D acceleration, then DRI/3D
acceleration, if these do not cause problems. This will make it much
easier to get the problematic video drivers fixed.
Lee
Definitely a good strategy, but nobody is going to take a system with no
video acceleration seriously.
10:35 p.m.
On Saturday 07 August 2004 07:17 pm, Lee Revell wrote:
On Sat, 2004-08-07 at 18:50, John Check wrote:
Indeed. I've had to do the process of elimination thing to get people to
own up to problems, so I appreciate that.
Just FYI and directed to the list at large; When I say things like that, it's
not meant personally.
On Saturday 07 August 2004 06:30 pm, Lee Revell
wrote:
Yes, of course this is not a long term solution. The point is to get
the buggy video drivers fixed (this is open source after all), in order
to do that we need to be able to say 'when i enable DRI with $FOO
driver, I get xruns, and these go away when I disable it'. I recommend disabling all hardware video
acceleration when tuning a
system for low latency (set Option "NoAccel" and commend out the
"dri"
line). This will prevent X from interacting directly with your
hardware - it is complicated enough when only the kernel can access
hardware. Then, once you get that working, re-enable 2D acceleration,
then DRI/3D acceleration, if these do not cause problems. This will
make it much easier to get the problematic video drivers fixed.
Lee
Definitely a good strategy, but nobody is going to take a system with no
video acceleration seriously.
Lee
8 Aug
8 Aug
8:20 p.m.
On Sat, 2004-08-07 at 16:17, Lee Revell wrote:
On Sat, 2004-08-07 at 18:50, John Check wrote:
Yes, of course this is not a long term solution. The point is to get
the buggy video drivers fixed (this is open source after all), in order
to do that we need to be able to say 'when i enable DRI with $FOO
driver, I get xruns, and these go away when I disable it'.
Here's one case. 2.6.8rc2-mm2 + voluntary O3, lsm module, kernel config
files derived from current default FC2's, very recent alsa CVS (post
1.0.6rc2), FC2, xorg, gnome desktop, P4 laptop 1.7GHz/512M with Radeon
video chipset and Intel Corp. 82801CA/CAM AC'97 Audio Controller,
kernel_preempt=1, voluntary_preempt=3, acpi=on (sound does not work with
acpi=off), irq's left in default state[*]
With "Option NoAccel" and an idle jack in an xterm (-p128 -n2), start
glxgears, move the window around and there are no xruns (any size
window).
With acceleration enabled, start glxgears and with the default size move
the window around, no xruns. Enlarging the window (this is on a
1600x1200 screen) eventually triggers tons of xruns when the window is
moved and is "large enough".
Samples of output from jack:
**** alsa_pcm: xrun of at least 7.470 msecs
**** alsa_pcm: xrun of at least 7.401 msecs
**** alsa_pcm: xrun of at least 7.438 msecs
delay of 5728.000 usecs exceeds estimated spare time of 2644.000;
restart ...
**** alsa_pcm: xrun of at least 7.482 msecs
**** alsa_pcm: xrun of at least 7.216 msecs
**** alsa_pcm: xrun of at least 7.476 msecs
And this is on the kernel log (two samples):
ALSA
/usr/src/redhat/BUILD/alsa-driver-1.0.6rc2/alsa-kernel/core/pcm_lib.c:211: Unexpected
hw_pointer value [1] (stream = 0, delta: -126, max jitter = 128): wrong interrupt
acknowledge?
[<e0ba9f0f>] snd_pcm_period_elapsed+0x2cf/0x560 [snd_pcm]
[<c011e9f7>] __wake_up_common+0x37/0x70
[<e0ad620d>] snd_intel8x0_interrupt+0x29d/0x360 [snd_intel8x0]
[<c0225f30>] acpi_ev_gpe_detect+0xf7/0x103
[<c012a9a0>] generic_handle_IRQ_event+0x30/0x60
[<c012ab0c>] do_hardirq+0x13c/0x3a0
[<c012b7f0>] do_irqd+0x0/0x80
[<c012b848>] do_irqd+0x58/0x80
[<c01420e8>] kthread+0x98/0xa0
[<c0142050>] kthread+0x0/0xa0
[<c010429d>] kernel_thread_helper+0x5/0x18
ALSA
/usr/src/redhat/BUILD/alsa-driver-1.0.6rc2/alsa-kernel/core/pcm_lib.c:139: XRUN: pcmC0D0c
[<e0ba9faf>] snd_pcm_period_elapsed+0x36f/0x560 [snd_pcm]
[<c011e9f7>] __wake_up_common+0x37/0x70
[<e0ad620d>] snd_intel8x0_interrupt+0x29d/0x360 [snd_intel8x0]
[<c0225f30>] acpi_ev_gpe_detect+0xf7/0x103
[<c012a9a0>] generic_handle_IRQ_event+0x30/0x60
[<c012ab0c>] do_hardirq+0x13c/0x3a0
[<c012b7f0>] do_irqd+0x0/0x80
[<c012b848>] do_irqd+0x58/0x80
[<c01420e8>] kthread+0x98/0xa0
[<c0142050>] kthread+0x0/0xa0
[<c010429d>] kernel_thread_helper+0x5/0x18
ALSA
/usr/src/redhat/BUILD/alsa-driver-1.0.6rc2/alsa-kernel/core/pcm_lib.c:211: Unexpected
hw_pointer value [1] (stream = 1, delta: -38, max jitter = 128): wrong interrupt
acknowledge?
[<e0ba9f0f>] snd_pcm_period_elapsed+0x2cf/0x560 [snd_pcm]
[<c011e9f7>] __wake_up_common+0x37/0x70
[<e0ad620d>] snd_intel8x0_interrupt+0x29d/0x360 [snd_intel8x0]
[<c0225f30>] acpi_ev_gpe_detect+0xf7/0x103
[<c012a9a0>] generic_handle_IRQ_event+0x30/0x60
[<c012ab0c>] do_hardirq+0x13c/0x3a0
[<c012b7f0>] do_irqd+0x0/0x80
[<c012b848>] do_irqd+0x58/0x80
[<c01420e8>] kthread+0x98/0xa0
[<c0142050>] kthread+0x0/0xa0
[<c010429d>] kernel_thread_helper+0x5/0x18
ALSA
/usr/src/redhat/BUILD/alsa-driver-1.0.6rc2/alsa-kernel/core/pcm_lib.c:139: XRUN: pcmC0D0p
[<e0ba9faf>] snd_pcm_period_elapsed+0x36f/0x560 [snd_pcm]
[<c011e9f7>] __wake_up_common+0x37/0x70
[<e0ad620d>] snd_intel8x0_interrupt+0x29d/0x360 [snd_intel8x0]
[<c0225f30>] acpi_ev_gpe_detect+0xf7/0x103
[<c012a9a0>] generic_handle_IRQ_event+0x30/0x60
[<c012ab0c>] do_hardirq+0x13c/0x3a0
[<c012b7f0>] do_irqd+0x0/0x80
[<c012b848>] do_irqd+0x58/0x80
[<c01420e8>] kthread+0x98/0xa0
[<c0142050>] kthread+0x0/0xa0
[<c010429d>] kernel_thread_helper+0x5/0x18
Does not look very helpful...
-- Fernando
[*] almost everything shares IRQ9..... sigh...
9: 1480257 XT-PIC acpi, uhci_hcd, uhci_hcd, uhci_hcd,
eth0, yenta, yenta, Intel 82801CA-ICH3, radeon@PCI:1:0:0
On Saturday 07 August 2004 06:30 pm, Lee Revell
wrote:
I
recommend disabling all hardware video acceleration when tuning a
system for low latency (set Option "NoAccel" and commend out the
"dri"
line). This will prevent X from interacting directly with your hardware
- it is complicated enough when only the kernel can access hardware.
Then, once you get that working, re-enable 2D acceleration, then DRI/3D
acceleration, if these do not cause problems. This will make it much
easier to get the problematic video drivers fixed.
Definitely a good strategy, but nobody is going to take a system with no
video acceleration seriously.
10 Aug
10 Aug
3:56 p.m.
On Sun, 2004-08-08 at 15:05, Fernando Pablo Lopez-Lezcano wrote:
On Sat, 2004-08-07 at 16:17, Lee Revell wrote:
Still the same result on rc3, voluntary O4...
Will test soon on rc3/O5.
Anything else I can do to better debug these latency spikes?
(they also probably happen in the mga and r128 drivers)
-- Fernando
On Sat, 2004-08-07 at 18:50, John Check wrote:
Here's one case. 2.6.8rc2-mm2 + voluntary O3, On Saturday 07 August 2004 06:30 pm, Lee Revell
wrote:
Yes, of course this is not a long term solution. The point is to get
the buggy video drivers fixed (this is open source after all), in order
to do that we need to be able to say 'when i enable DRI with $FOO
driver, I get xruns, and these go away when I disable it'. I recommend disabling all hardware video
acceleration when tuning a
system for low latency (set Option "NoAccel" and commend out the
"dri"
line). This will prevent X from interacting directly with your hardware
- it is complicated enough when only the kernel can access hardware.
Then, once you get that working, re-enable 2D acceleration, then DRI/3D
acceleration, if these do not cause problems. This will make it much
easier to get the problematic video drivers fixed.
Definitely a good strategy, but nobody is going to take a system with no
video acceleration seriously. lsm module, kernel config
files derived from current default FC2's, very recent alsa CVS (post
1.0.6rc2), FC2, xorg, gnome desktop, P4 laptop 1.7GHz/512M with Radeon
video chipset and Intel Corp. 82801CA/CAM AC'97 Audio Controller,
kernel_preempt=1, voluntary_preempt=3, acpi=on (sound does not work with
acpi=off), irq's left in default state[*]
With "Option NoAccel" and an idle jack in an xterm (-p128 -n2), start
glxgears, move the window around and there are no xruns (any size
window).
With acceleration enabled, start glxgears and with the default size move
the window around, no xruns. Enlarging the window (this is on a
1600x1200 screen) eventually triggers tons of xruns when the window is
moved and is "large enough".
Samples of output from jack:
**** alsa_pcm: xrun of at least 7.470 msecs
**** alsa_pcm: xrun of at least 7.401 msecs
**** alsa_pcm: xrun of at least 7.438 msecs
delay of 5728.000 usecs exceeds estimated spare time of 2644.000;
restart ...
**** alsa_pcm: xrun of at least 7.482 msecs
**** alsa_pcm: xrun of at least 7.216 msecs
**** alsa_pcm: xrun of at least 7.476 msecs
8 Aug
8 Aug
2:02 a.m.
On Fri, 2004-08-06 at 22:24, Lee Revell wrote:
As Ingo's patches stabilize, it is very important
for more people to
test them. With 2.6.8+voluntary-preempt-O3, using voluntary_preempt=3,
kernel_preemption=1, and the soundcard and RTC irqs non-threaded, it
works for me (tm) - I have been unable to produce a latency over 50
usecs, even while punishing the machine with parallel builds and iozone
-a.
We need people to test with different hardware configurations and
workloads. Especially needed are testers with ACPI, APIC, SMP, HT
machines. There are still some ACPI related bugs, more testers are
needed to nail these down. There are some reports of lockups which I
cannot reproduce.
Lee, thanks for the summary. I'll definitely give it a spin and report
any problems to LKML.
Anyone knows whether mingo@redhat is taking a vacation or something? The
voluntary-preempt patch is for 2.6.8-rc2, and it's been several days now
since rc3 is out. In fact his rc2 patch has the same date as the
official rc3 kernel. :-/
--
Florin Andrei
http://florin.myip.org/
2:15 a.m.
On Sat, 2004-08-07 at 23:47, Florin Andrei wrote:
Anyone knows whether mingo@redhat is taking a vacation or something? The
voluntary-preempt patch is for 2.6.8-rc2, and it's been several days now
since rc3 is out. In fact his rc2 patch has the same date as the
official rc3 kernel. :-/
Probably just waiting for 2.6.8 to be released, rather than constantly
updating the patch to track the release candidates.
Lee
9 Aug
9 Aug
2:22 a.m.
On Sat, 2004-08-07 at 20:47, Florin Andrei wrote:
Anyone knows whether mingo@redhat is taking a vacation
or something? The
voluntary-preempt patch is for 2.6.8-rc2, and it's been several days now
since rc3 is out. In fact his rc2 patch has the same date as the
official rc3 kernel. :-/
Ingo says the voluntary-preempt-2.6.8-rc2-O3 patch will apply cleanly to
linux-2.6.8-rc3
I didn't test it, though.
--
Florin Andrei
http://florin.myip.org/
8 Aug
8 Aug
2:19 a.m.
On Fri, 2004-08-06 at 22:24, Lee Revell wrote:
As Ingo's patches stabilize, it is very important
for more people to
test them. With 2.6.8+voluntary-preempt-O3, using voluntary_preempt=3,
kernel_preemption=1, and the soundcard and RTC irqs non-threaded, it
works for me (tm) - I have been unable to produce a latency over 50
usecs, even while punishing the machine with parallel builds and iozone
-a.
What is the reason to run the RTC IRQ non-threaded?
In general, why run certain IRQs non-threaded?
--
Florin Andrei
http://florin.myip.org/
2:42 a.m.
On Sun, 2004-08-08 at 00:04, Florin Andrei wrote:
On Fri, 2004-08-06 at 22:24, Lee Revell wrote:
This ensures that those interrupts have the highest priority of anything
on the system. The soundcard is important for obvious reasons, and the
RTC is used for midi timing. These are also the only two devices on the
system (other than the timer irq 0 which cannot be made threaded) whose
nature imposes an inherehent real time constraint on the system. For
any other device that can raise an interrupt, we can process it at our
leisure, but if we don't handle the sound card interrupt within the
period time we are hosed.
In practice I have found that if I do not make the rtc interrupt
non-threaded I get 'rtc: lost some interrupts at 1024 hz' messages when
using mplayer, and xruns in alsa unless i do the same for the sound
card.
Lee
As Ingo's patches stabilize, it is very
important for more people to
test them. With 2.6.8+voluntary-preempt-O3, using voluntary_preempt=3,
kernel_preemption=1, and the soundcard and RTC irqs non-threaded, it
works for me (tm) - I have been unable to produce a latency over 50
usecs, even while punishing the machine with parallel builds and iozone
-a.
What is the reason to run the RTC IRQ non-threaded?
In general, why run certain IRQs non-threaded? 
2:47 a.m.
On Sun, Aug 08, 2004 at 02:27:02PM EST, Lee Revell wrote:
This ensures that those interrupts have the highest
priority of anything
on the system. The soundcard is important for obvious reasons, and the
RTC is used for midi timing. These are also the only two devices on the
system (other than the timer irq 0 which cannot be made threaded) whose
nature imposes an inherehent real time constraint on the system. For
any other device that can raise an interrupt, we can process it at our
leisure, but if we don't handle the sound card interrupt within the
period time we are hosed.
Sorry, I haven't really been following the thread, but how do you set interrupts
to be non-threaded?
--
Luke Yelavich
http://www.audioslack.com
luke(a)audioslack.com
2:56 a.m.
On Sun, 2004-08-08 at 00:30, Luke Yelavich wrote:
On Sun, Aug 08, 2004 at 02:27:02PM EST, Lee Revell
wrote:
Just echo 0 > /proc/irq/foo/bar/threaded.
root@mindpipe:/home/rlrevell/testresults# find /proc/irq -name threaded -print -a -exec
cat {} \;
/proc/irq/15/ide1/threaded
1
/proc/irq/14/ide0/threaded
1
/proc/irq/12/uhci_hcd/threaded
1
/proc/irq/11/eth0/threaded
1
/proc/irq/11/uhci_hcd/threaded
1
/proc/irq/10/EMU10K1/threaded
0
/proc/irq/10/uhci_hcd/threaded
1
/proc/irq/8/rtc/threaded
0
/proc/irq/1/i8042/threaded
1
Lee
This ensures that those interrupts have the
highest priority of anything
on the system. The soundcard is important for obvious reasons, and the
RTC is used for midi timing. These are also the only two devices on the
system (other than the timer irq 0 which cannot be made threaded) whose
nature imposes an inherehent real time constraint on the system. For
any other device that can raise an interrupt, we can process it at our
leisure, but if we don't handle the sound card interrupt within the
period time we are hosed.
Sorry, I haven't really been following the thread, but how do you set interrupts
to be non-threaded? 
3:41 a.m.
Lee Revell wrote:
On Sun, 2004-08-08 at 00:30, Luke Yelavich wrote:
Is there any way to do this on a 2.4 kernel? Like say,
2.4.26-ll.rhfc1.ccrma, or is this already covered with how Fernando
configures the kernel?
Rick B
On Sun, Aug 08, 2004 at 02:27:02PM EST, Lee Revell
wrote:
Just echo 0 > /proc/irq/foo/bar/threaded.
root@mindpipe:/home/rlrevell/testresults# find /proc/irq -name threaded -print -a -exec
cat {} \;
/proc/irq/15/ide1/threaded
1
/proc/irq/14/ide0/threaded
1
/proc/irq/12/uhci_hcd/threaded
1
/proc/irq/11/eth0/threaded
1
/proc/irq/11/uhci_hcd/threaded
1
/proc/irq/10/EMU10K1/threaded
0
/proc/irq/10/uhci_hcd/threaded
1
/proc/irq/8/rtc/threaded
0
/proc/irq/1/i8042/threaded
1
Lee
This ensures that those interrupts have the
highest priority of anything
on the system. The soundcard is important for obvious reasons, and the
RTC is used for midi timing. These are also the only two devices on the
system (other than the timer irq 0 which cannot be made threaded) whose
nature imposes an inherehent real time constraint on the system. For
any other device that can raise an interrupt, we can process it at our
leisure, but if we don't handle the sound card interrupt within the
period time we are hosed.
Sorry, I haven't really been following the thread, but how do you set
interrupts
to be non-threaded?
4:06 a.m.
On Sun, 2004-08-08 at 01:28, Rick B wrote:
Is there any way to do this on a 2.4 kernel? Like
say,
2.4.26-ll.rhfc1.ccrma, or is this already covered with how Fernando
configures the kernel?
No, as the thread name implies, you need a recent 2.6 kernel with Ingo
Molnar's voluntary preemption patches to get these new features. I
believe CCRMA may have a 2.6.7+voluntary preempt package, but I don't
use it so I'm not sure. Even that package would not be likely to have
the irq threading feature, this area of kernel development has moved
very fast lately.
These features are still very new and not fully tested. I would imagine
more binary packages will become available in the next few weeks as the
voluntary preempt patches stabilize. For now more testers are needed
but be warned it probably wont be as stable as 2.4+ll now. 2.6 is still
not recommended if you need to get serious audio work done on any kind
of timetable. It will be ready very soon.
Once the voluntary preemption patches for 2.6 are stable then there will
really be no need to use 2.4+11 anymore, because the performance with
2.6+voluntary-preempt is much, much better.
Lee
8:51 a.m.
New subject: wiki page (was: Re: [linux-audio-user] dipping toes in 2.6 waters)
On Sun, 08 Aug 2004 01:51:28 -0400
Lee Revell <rlrevell(a)joe-job.com> wrote:
On Sun, 2004-08-08 at 01:28, Rick B wrote:
Hi, i just wanted to let you people know that i started a wiki page to
collect info which might be usable for users of 2.6.x who want to
achieve low latency on their system.. content is pretty much lacking
right now and my description of the effects of ingos volountary
preemption patches might be completely off. Maybe you people still want
to take a look and maybe fill with some meat.. Later this info could be
moved to the LAD/LAU site..
http://www.affenbande.org/~tapas/wiki/index.php?Low%20latency%20for%20audio…
Flo
P.S.: does anyone know how to make phpwiki use preformatted text?
--
Palimm Palimm!
http://affenbande.org/~tapas/
Is there any way to do this on a 2.4 kernel?
Like say,
2.4.26-ll.rhfc1.ccrma, or is this already covered with how Fernando
configures the kernel?
No, as the thread name implies, you need a recent 2.6 kernel with Ingo
Molnar's voluntary preemption patches to get these new features. I
believe CCRMA may have a 2.6.7+voluntary preempt package, but I don't
use it so I'm not sure. Even that package would not be likely to have
the irq threading feature, this area of kernel development has moved
very fast lately.
These features are still very new and not fully tested. I would
imagine more binary packages will become available in the next few
weeks as the voluntary preempt patches stabilize. For now more
testers are needed but be warned it probably wont be as stable as
2.4+ll now. 2.6 is still not recommended if you need to get serious
audio work done on any kind of timetable. It will be ready very soon.
Once the voluntary preemption patches for 2.6 are stable then there
will really be no need to use 2.4+11 anymore, because the performance
with 2.6+voluntary-preempt is much, much better. 
10:29 p.m.
New subject: wiki page (was: Re: [linux-audio-user] dipping toes in 2.6 waters)
Florian Schmidt <mista.tapas(a)gmx.net> writes:
Hi, i just wanted to let you people know that i
started a wiki page to
collect info which might be usable for users of 2.6.x who want to
achieve low latency on their system.. content is pretty much lacking
right now and my description of the effects of ingos volountary
preemption patches might be completely off. Maybe you people still want
to take a look and maybe fill with some meat.. Later this info could be
moved to the LAD/LAU site..
http://www.affenbande.org/~tapas/wiki/index.php?Low%20latency%20for%20audio…
Flo
P.S.: does anyone know how to make phpwiki use preformatted text?
--
Palimm Palimm!
http://affenbande.org/~tapas/
--
joq
10:31 p.m.
New subject: wiki page (was: Re: [linux-audio-user] dipping toes in 2.6 waters)
Florian Schmidt <mista.tapas(a)gmx.net> writes:
Hi, i just wanted to let you people know that i
started a wiki page to
collect info which might be usable for users of 2.6.x who want to
achieve low latency on their system.. content is pretty much lacking
right now and my description of the effects of ingos volountary
preemption patches might be completely off. Maybe you people still want
to take a look and maybe fill with some meat.. Later this info could be
moved to the LAD/LAU site..
http://www.affenbande.org/~tapas/wiki/index.php?Low%20latency%20for%20audio…
Good work!
--
joq
11:28 p.m.
New subject: wiki page (was: Re: [linux-audio-user] dipping toes in 2.6 waters)
On 08 Aug 2004 19:16:20 -0500
"Jack O'Quin" <joq(a)io.com> wrote:
nice to hear :) here's a shorter link [evil redirect but makes the url
more readable]:
http://affenbande.org/~tapas/linux-2.6.x-ll.html
Flo
--
Palimm Palimm!
http://affenbande.org/~tapas/
9 Aug
9 Aug
2:05 a.m.
New subject: wiki page (was: Re: [linux-audio-user] dipping toes in 2.6 waters)
On Sun, 2004-08-08 at 21:23, Florian Schmidt wrote:
On 08 Aug 2004 19:16:20 -0500
"Jack O'Quin" <joq(a)io.com> wrote:
nice to hear :) here's a shorter link [evil redirect but makes the url
more readable]:
http://affenbande.org/~tapas/linux-2.6.x-ll.html
It looks like many latency fixes from the voluntary preemption patch are
going into the -mm series. Search this post for 'latency', it appears
that the filemap_sync issue (which caused apt-get to trigger an xrun) is
addressed, as well as several others. One of the more interesting items
added is 'low latency RCU'.
So, althouh Ingo has been quieter lately, problems are being fixed.
Here is the announcement:
http://lkml.org/lkml/2004/8/8/125
There is no voluntary preemption patch available yet for -mm2, as this
annonucement is just a few hours old. It seems likely that future
'voluntary preemption' patches for the -mm series would consist of
little more than the irq-threading feature. This would fit the new
development model very well.
Lee
10:02 a.m.
New subject: wiki page (was: Re: [linux-audio-user] dipping toes in 2.6 waters)
On Sun, 08 Aug 2004 23:50:35 -0400
Lee Revell <rlrevell(a)joe-job.com> wrote:
It looks like many latency fixes from the voluntary
preemption patch
are going into the -mm series. Search this post for 'latency', it
appears that the filemap_sync issue (which caused apt-get to trigger
an xrun) is addressed, as well as several others. One of the more
interesting items added is 'low latency RCU'.
Ah ok, but i wonder how this can have any effect w/o the rest of the
voluntary preemption stuff? I don't see the VP keyword in the lkml
post..
So, althouh Ingo has been quieter lately, problems are being fixed.
Here is the announcement:
http://lkml.org/lkml/2004/8/8/125
There is no voluntary preemption patch available yet for -mm2, as this
annonucement is just a few hours old. It seems likely that future
'voluntary preemption' patches for the -mm series would consist of
little more than the irq-threading feature. This would fit the new
development model very well.
btw: O4 against rc3 has just been announced..
Flo
--
Palimm Palimm!
http://affenbande.org/~tapas/
4:20 p.m.
New subject: wiki page (was: Re: [linux-audio-user] dipping toes in 2.6 waters)
On Sun, 2004-08-08 at 06:45, Florian Schmidt wrote:
On Sun, 08 Aug 2004 01:51:28 -0400
Here is an excerpt from "Unix Internals" by Uresh Vahalia that explains
the situation much better than I could. I am not sure what the
copyright implications of posting this are, possibly it is short enough
to be OK, but I will let you be the judge of whether to post it on the
wiki.
This text describes the Solaris implementation of interrupt threads vs.
the traditional method. It applies very well to Ingo's patch.
"Interrupt handlers often manipulate data shared by the rest of the
kernel. This requires the kernel to synchronize access to shared data.
In traditional UNIX, the kernel achieves this by raising the
<it>interrupt priority level (ipl)<it> to block relevant interrupts
while executing code that accesses such data (...).
This model has many drawbacks ... Interrupts are important and urgent
events, and blocking them degrades performance in many ways ...
Solaris replaces the traditional interrupt and synchronization model
with a new implementation [Eykh 92, Klei 95] that aims to improve
performance (...) it does not use IPLs for interrupts... it employs a
set of kernel threads to handle interrupts. These <it>kernel
threads</it> can be created on the fly and are assigned a higher
priority than all other types of threads. They use the same
synchronization primitives as other threads and thus can block if they
need a resource held by another thread. The kernel blocks interrupts
only in a few exceptional situations, such as when acquiring the mutex
lock that protects a <it>sleep queue</it>.
Although the creation of kernel threads is relatively lightweight, it is
still too expensive to create a new thread for each interrupt. The
kernel maintains a pool of interrupt threads, which are preallocated and
partially initialized. By default, this pool contains one thread per
interrupt level for each CPU, plus a single systemwide thread for the
clock."
My explanation:
Basically, with non-threaded interrupts, anytime an interrupt occurs the
interrupt handler runs immediately, blocking additional interrupts from
the same device while it is running. This means than an interrupt
handler can interrupt another interrupt handler, say, if we get a disk
i/o completion in the middle of snd_pcm_period_elapsed.
With threaded interrupts, an interrupt arriving from the disk controller
does not immediately cause the disk irq handler to run, interrupting
whatever was going on, but marks the disk irq thread as ready to run.
Since interrupt threads run at the highest priority, this will usually
cause the disk irq handler to be scheduled and run immediately, unless
we are executing a *non-threaded* interrupt handler. This is the
advantage of the mixed model - where the soundcard interrupt handler
would previously have been interrupted, in this case the disk irq
handler will run as soon as the soundcard irq handler exits.
By default, if all irqs are threaded, all the threads run at the same
priority. This means that if we get interrupts from both the soundcard
and disk while a third handler is running (say the timer). both will be
queued, and possibly the disk irq thread will get scheduled before the
soundcard irq thread, leading to xruns.
I believe you could achieve the same result as setting the soundcard irq
non-threaded by having all irqs threaded, and setting the priority for
the soundcard interrupt handler thread higher than the others. I have
not tested this.
Lee
4:46 p.m.
New subject: wiki page (was: Re: [linux-audio-user] dipping toes in 2.6 waters)
On Mon, 2004-08-09 at 14:05, Lee Revell wrote:
On Sun, 2004-08-08 at 06:45, Florian Schmidt wrote:
Also, I get the same latencies using 256 for max_sectors_kb as 16. I
also cannot measure a decrease in disk throughput. If you get the same
results, maybe the wiki page should be updated.
Lee
On Sun, 08 Aug 2004 01:51:28 -0400
6:53 p.m.
New subject: wiki page (was: Re: [linux-audio-user] dipping toes in 2.6 waters)
On Mon, 09 Aug 2004 14:31:11 -0400
Lee Revell <rlrevell(a)joe-job.com> wrote:
On Mon, 2004-08-09 at 14:05, Lee Revell wrote:
Hmm, in my case the maximum value i can use is 128, and i cannot see a
difference between 128 and 16 either. It didn't do harm. My guess that
this might impact throughput was based on the assumption that the
overhead increases with smaller sizes. I might be wrong.
Do you have a max_hw_sectors_kb greater than 128? I think it has changed
somewhere during the last kernel versions. I seem to remember that this
was 256 once..
Flo
--
Palimm Palimm!
http://affenbande.org/~tapas/
On Sun, 2004-08-08 at 06:45, Florian Schmidt
wrote:
Also, I get the same latencies using 256 for max_sectors_kb as 16. I
also cannot measure a decrease in disk throughput. If you get the
same results, maybe the wiki page should be updated. On Sun, 08 Aug 2004 01:51:28 -0400
9:38 p.m.
New subject: wiki page (was: Re: [linux-audio-user] dipping toes in 2.6 waters)
On Mon, 2004-08-09 at 13:48, Florian Schmidt wrote:
Hmm, in my case the maximum value i can use is 128,
and i cannot see a
difference between 128 and 16 either. It didn't do harm.
Maybe it vastly depends on the workload? You know, like writing a tiny
44.1/16/2 audio stream to disk versus writing a huge raw video stream
(or a large database workload).
What was your disk workload?
--
Florin Andrei
http://florin.myip.org/
10:18 p.m.
New subject: wiki page (was: Re: [linux-audio-user] dipping toes in 2.6 waters)
On Mon, 2004-08-09 at 19:23, Florin Andrei wrote:
On Mon, 2004-08-09 at 13:48, Florian Schmidt wrote:
I tried every disk torture benchmark I could think of - bonnie++,
sysbench, dbench, iozone. I also tried stressing the CPU/scheduler with
parallel builds and CPU stress tests. Stressing the system increases
the average latency slightly (I have graphs at
http://www.members.dca.net/rlrevell/testresults/) but does not affect
the worst case at all. I am guessing whatever code path is involved in
the higher latencies is not filesystem-related.
The 128 vs 1024 default has to do with whether 48-bit addressing is
enabled. This will be enabled for larger disks (120GB+?). So, the size
of your disk affects the maximum amount of IO that can be in flight at
once. This was covered in one of the recent lkml threads, check the
archives.
Lee
Hmm, in my case the maximum value i can use is
128, and i cannot see a
difference between 128 and 16 either. It didn't do harm.
Maybe it vastly depends on the workload? You know, like writing a tiny
44.1/16/2 audio stream to disk versus writing a huge raw video stream
(or a large database workload).
What was your disk workload?
7:05 p.m.
New subject: wiki page (was: Re: [linux-audio-user] dipping toes in 2.6 waters)
On Mon, 09 Aug 2004 14:05:26 -0400
Lee Revell <rlrevell(a)joe-job.com> wrote:
Here is an excerpt from "Unix Internals" by
Uresh Vahalia that
explains the situation much better than I could. I am not sure what
the copyright implications of posting this are, possibly it is short
enough to be OK, but I will let you be the judge of whether to post it
on the wiki.
No, i will not put a verbatim copy of this onto the wiki. I will try to
extract the relevant information.
This text describes the Solaris implementation of interrupt threads
vs. the traditional method. It applies very well to Ingo's patch.
Ok
These <it>kernel
threads</it> can be created on the fly and are assigned a higher
priority than all other types of threads.
This seems to be not true for the threaded IRQ handlers in VP [top
extract]:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
118 root 5 -10 0 0 0 S 0.0 0.0 0:00.00 IRQ 5
mango:~# chrt -p 118
pid 118's current scheduling policy: SCHED_OTHER
pid 118's current scheduling priority: 0
Or do chrt and top print wrong infos? Or do i just read them wrong? I'm
especially amazed about the SCHED_OTHER.
Basically, with non-threaded interrupts, anytime an
interrupt occurs
the interrupt handler runs immediately, blocking additional interrupts
from the same device while it is running. This means than an
interrupt handler can interrupt another interrupt handler, say, if we
get a disk i/o completion in the middle of snd_pcm_period_elapsed.
Hmm, isn't it the case that the traditional IRQ handler blocks all
further IRQ's until it is done? I suppose there was a hierarchy of some
kind. I read about the ipl in the text you quoted but didn't understand
it really..
With threaded interrupts, an interrupt arriving from the disk
controller does not immediately cause the disk irq handler to run,
interrupting whatever was going on, but marks the disk irq thread as
ready to run. Since interrupt threads run at the highest priority,
this will usually cause the disk irq handler to be scheduled and run
immediately, unless we are executing a *non-threaded* interrupt
handler. This is the advantage of the mixed model - where the
soundcard interrupt handler would previously have been interrupted, in
this case the disk irq handler will run as soon as the soundcard irq
handler exits.
Yes, this makes sense..
By default, if all irqs are threaded, all the threads run at the same
priority. This means that if we get interrupts from both the
soundcard and disk while a third handler is running (say the timer).
both will be queued, and possibly the disk irq thread will get
scheduled before the soundcard irq thread, leading to xruns.
I believe you could achieve the same result as setting the soundcard
irq non-threaded by having all irqs threaded, and setting the priority
for the soundcard interrupt handler thread higher than the others. I
have not tested this.
Me neither, but it makes sense..
--
Palimm Palimm!
http://affenbande.org/~tapas/
7:24 p.m.
New subject: wiki page (was: Re: [linux-audio-user] dipping toes in 2.6 waters)
On Mon, 2004-08-09 at 17:00, Florian Schmidt wrote:
I think Linux does not have ipls as such. When an interrupt handler is
running it blocks further interrupts from the same source, but without
the voluntary preempt patch, an interrupt from the disk will interrupt
the soundcard interrupt handler. If you were to extend this scheme to
support more than one priority (as opposed to 'this interrupt source' vs
'other interrupt source'), you would have IPLs.
I think that threading all interrupts and setting relative priorities
would give you IPLs on Linux. More testing is required.
Lee
On Mon, 09 Aug 2004 14:05:26 -0400
Lee Revell <rlrevell(a)joe-job.com> wrote:
OK. I am going to plug the book however because it's so good:
http://www.amazon.com/exec/obidos/tg/detail/-/0131019082?v=glance.
Here is an excerpt from "Unix
Internals" by Uresh Vahalia that
explains the situation much better than I could. I am not sure what
the copyright implications of posting this are, possibly it is short
enough to be OK, but I will let you be the judge of whether to post it
on the wiki.
This seems to be not true for the threaded IRQ
handlers in VP [top
extract]:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
118 root 5 -10 0 0 0 S 0.0 0.0 0:00.00 IRQ 5
mango:~# chrt -p 118
pid 118's current scheduling policy: SCHED_OTHER
pid 118's current scheduling priority: 0
Or do chrt and top print wrong infos? Or do i just read them wrong? I'm
especially amazed about the SCHED_OTHER.
You are correct, they run at the same elevated priority as all kernel
threads, not higher. This would explain why X activity can delay the
interrupt handlers with the default settings - on Debian the X server
runs at nice -10. I am pretty sure that one patch series (-L or -M) ran
the interrupt threads reniced to -51.
Basically,
with non-threaded interrupts, anytime an interrupt occurs
the interrupt handler runs immediately, blocking additional interrupts
from the same device while it is running. This means than an
interrupt handler can interrupt another interrupt handler, say, if we
get a disk i/o completion in the middle of snd_pcm_period_elapsed.
Hmm, isn't it the case that the traditional IRQ handler blocks all
further IRQ's until it is done? I suppose there was a hierarchy of some
kind. I read about the ipl in the text you quoted but didn't understand
it really..
7:36 p.m.
New subject: wiki page (was: Re: [linux-audio-user] dipping toes in 2.6 waters)
On Mon, 09 Aug 2004 17:08:57 -0400
Lee Revell <rlrevell(a)joe-job.com> wrote:
I have sent a mail to Ingo asking for clarification.
Flo
--
Palimm Palimm!
http://affenbande.org/~tapas/
OK. I am going to plug the book however because
it's so good:
http://www.amazon.com/exec/obidos/tg/detail/-/0131019082?v=glance.
It really looks good :)
This seems to be not true for the threaded IRQ
handlers in VP [top
extract]:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
118 root 5 -10 0 0 0 S 0.0 0.0 0:00.00 IRQ 5
mango:~# chrt -p 118
pid 118's current scheduling policy: SCHED_OTHER
pid 118's current scheduling priority: 0
Or do chrt and top print wrong infos? Or do i just read them wrong?
I'm especially amazed about the SCHED_OTHER.
You are correct, they run at the same elevated priority as all kernel
threads, not higher. This would explain why X activity can delay the
interrupt handlers with the default settings - on Debian the X server
runs at nice -10. I am pretty sure that one patch series (-L or -M)
ran the interrupt threads reniced to -51.
10 Aug
10 Aug
6:39 p.m.
New subject: wiki page (was: Re: [linux-audio-user] dipping toes in 2.6 waters)
On Mon, 09 Aug 2004 17:08:57 -0400
Lee Revell <rlrevell(a)joe-job.com> wrote:
I think Linux does not have ipls as such. When an
interrupt handler
is running it blocks further interrupts from the same source, but
without the voluntary preempt patch, an interrupt from the disk will
interrupt the soundcard interrupt handler. If you were to extend this
scheme to support more than one priority (as opposed to 'this
interrupt source' vs'other interrupt source'), you would have IPLs.
hi, i have to ask again, because there are still some unclarities for
me:
from links like this
http://roht.informatik.uni-halle.de/~ladischc/linux_interrupt_priorities.ht…
i get to the conclusion that there indeed was a hierarchy of IRQ's in
the traditional IRQ handlers in linux. I think this priority is located
in the PIC itself. I just don't know exactly how to understand the
implications. Does this priority only apply to irqs which happen to
happen on the exact same pci bus cycle? So, if soundcard and hd raise an
interrupt at the same time, the one with the higher PIC priority gets
precedence.. All this is still independent of the linux IRQ handlers. I
assume these PIC priorities still are effective when using threaded IRQ
handlers.
Now the question is: what happens in linux' traditional IRQ handler?
Does it honour PIC priorities? Let's assume an ide controller IRQ has
occured. Linux will handle it by running this irq's handler. This irq
handler disables further IRQ's from the same ide controller while it
runs. And reenable them when it finishes. Now during the running of the
irq handler a soundcard IRQ occurs. What happens? Does the PIC priority
have any influence on if the the Soundcards irq handler preempts the
ide-controller irq handler? Or does an irq from another source _always_
preempt irq handlers from other sources? In the case of threaded
handlers this is pretty clear. Only higher priority [not PIC priority
but task priority] irq handlers will preempt lower priority ones. But in
the case of traditional handlers?
Flo
--
Palimm Palimm!
http://affenbande.org/~tapas/
6:51 p.m.
New subject: wiki page (was: Re: [linux-audio-user] dipping toes in 2.6 waters)
On Tue, 2004-08-10 at 16:33, Florian Schmidt wrote:
On Mon, 09 Aug 2004 17:08:57 -0400
i get to the conclusion that there indeed was a
hierarchy of IRQ's in
the traditional IRQ handlers in linux. I think this priority is located
in the PIC itself. I just don't know exactly how to understand the
implications. Does this priority only apply to irqs which happen to
happen on the exact same pci bus cycle?
Yes, I think that is all the this means.
So, if soundcard and hd raise an
interrupt at the same time, the one with the higher PIC priority gets
precedence.. All this is still independent of the linux IRQ handlers. I
assume these PIC priorities still are effective when using threaded IRQ
handlers.
Yes, because this lives in the hardware. I don't think these priorities
matter much to us.
Now the question is: what happens in linux' traditional IRQ handler?
Does it honour PIC priorities? Let's assume an ide controller IRQ has
occured. Linux will handle it by running this irq's handler. This irq
handler disables further IRQ's from the same ide controller while it
runs. And reenable them when it finishes. Now during the running of the
irq handler a soundcard IRQ occurs. What happens?
The disk irq handler will get interrupted by the soundcard, the
soundcard interrupt handler will run, then return control to the disk
interrupt handler. You would think this wouldn't work very well, but
interrupt handlers run quickly, and with further interrupts from the
same source disabled, so interrupt storms do not occur.
However, if it happens the other way, and the disk controller interrupts
the soundcard, this can be a problem, because at the lowest latencies we
have 666 usecs between soundcard interrupts. If the disk controller
interrupts the soundcard and runs for a significant fraction of 666
usecs, then it's possible that by the time control is returned to the
soundcard interrupt handler, we have already missed the next interrupt.
I believe this is what was happening with the earler voluntary
preemption patches (-L2?), where xruns occurred with the default
max_sectors_kb of 1024, but went away when this was lowered to 256.
Lee
7:12 p.m.
New subject: wiki page (was: Re: [linux-audio-user] dipping toes in 2.6 waters)
On Tue, 10 Aug 2004 16:36:47 -0400
Lee Revell <rlrevell(a)joe-job.com> wrote:
However, if it happens the other way, and the disk
controller
interrupts the soundcard, this can be a problem, because at the lowest
latencies we have 666 usecs between soundcard interrupts. If the disk
controller interrupts the soundcard and runs for a significant
fraction of 666 usecs, then it's possible that by the time control is
returned to the soundcard interrupt handler, we have already missed
the next interrupt.
I believe this is what was happening with the earler voluntary
preemption patches (-L2?), where xruns occurred with the default
max_sectors_kb of 1024, but went away when this was lowered to 256.
Ok, thanks for the clarification. Now i can start trying to puzzle all
this info together into a nice short clear text on the wiki page. I'm
not so good at writing texts, so it might take a while :)
Flo
--
Palimm Palimm!
http://affenbande.org/~tapas/
11 Aug
11 Aug
1:07 a.m.
New subject: wiki page (was: Re: [linux-audio-user] dipping toes in 2.6 waters)
On Tue, 2004-08-10 at 17:07, Florian Schmidt wrote:
Ok, thanks for the clarification. Now i can start
trying to puzzle all
this info together into a nice short clear text on the wiki page. I'm
not so good at writing texts, so it might take a while :)
I have written a PHP version of this Perl script:
http://www.oddmuse.org/cgi-bin/oddmuse/GnuPlot_Extension to generate
gnuplot graphs from the latency histograms produced by JACK. You just
create a directory under your wwwroot and put a bunch of files in it,
with just an X and Y value per line and it generates two graphs per
file, one with a linear and one with a logarithmic scale:
http://krustophenia.net/testresults.php?dataset=2.6.8-rc3-O5
Here is the source:
http://krustophenia.net/testresults.phps
I only have the one data set up now, I will be posting numbers for the
latest -mm version of the voluntary preempt patch.
NOTE: The web server is my desktop machine so please don't complain if
it's inaccessible for a bit or gives an error.
Lee
2:48 a.m.
New subject: wiki page (was: Re: [linux-audio-user] dipping toes in 2.6 waters)
On Tue, 2004-08-10 at 22:52, Lee Revell wrote:
Compare these results for 2.6.8-rc3-mm2, without the voluntary
preemption patch:
http://krustophenia.net/testresults.php?dataset=2.6.8-rc3-mm2
Lee
3:05 a.m.
New subject: wiki page (was: Re: [linux-audio-user] dipping toes in 2.6 waters)
60 us worst-case latency, now that's more like it.
Voluntary preemption sounds a bit scary though, as in, it may be burning up
too much CPU trying to reschedule.
I also wonder how many drivers need patching.
=MB=
--
A focus on Quality.
4:03 a.m.
New subject: wiki page (was: Re: [linux-audio-user] dipping toes in 2.6 waters)
On Wed, 2004-08-11 at 00:50, Malcolm Baldridge wrote:
60 us worst-case latency, now that's more like it.
Voluntary preemption sounds a bit scary though, as in, it may be burning up
too much CPU trying to reschedule.
I also wonder how many drivers need patching.
Here are some results for 2.6.8-rc2-mm2 + voluntary-preempt O3. As I
suspected, the latency is about 10-20% better than with the stock kernel
+ voluntary-preempt.
http://krustophenia.net/testresults.php?dataset=2.6.8-rc2-mm2-O3
Lee
8:40 p.m.
New subject: wiki page (was: Re: [linux-audio-user] dipping toes in 2.6 waters)
On Tue, 2004-08-10 at 14:07, Florian Schmidt wrote:
Ok, thanks for the clarification. Now i can start
trying to puzzle all
this info together into a nice short clear text on the wiki page. I'm
not so good at writing texts, so it might take a while :)
The wiki is awesome. Keep up the good work!
--
Florin Andrei
http://florin.myip.org/
10 p.m.
New subject: wiki page (was: Re: [linux-audio-user] dipping toes in 2.6 waters)
On Wed, 11 Aug 2004 15:25:08 -0700
Florin Andrei <florin(a)andrei.myip.org> wrote:
On Tue, 2004-08-10 at 14:07, Florian Schmidt wrote:
Thanks for the heads up :) I will try my best.
Flo
--
Palimm Palimm!
http://affenbande.org/~tapas/
Ok, thanks for the clarification. Now i can start
trying to puzzle
all this info together into a nice short clear text on the wiki
page. I'm not so good at writing texts, so it might take a while :)
The wiki is awesome. Keep up the good work! 
10 Aug
10 Aug
7:34 p.m.
New subject: wiki page (was: Re: [linux-audio-user] dipping toes in 2.6 waters)
On Tue, Aug 10, 2004 at 10:33:56PM +0200, Florian Schmidt wrote:
i get to the conclusion that there indeed was a
hierarchy of IRQ's in
the traditional IRQ handlers in linux. I think this priority is located
in the PIC itself. I just don't know exactly how to understand the
implications. Does this priority only apply to irqs which happen to
happen on the exact same pci bus cycle?
I think ithere's a bigger window than that. If two IRQs happen any time
while interrupts are disabled during the service routine for another
interrupt, the higher priority one gets executed when interrupts
are re-enabled.
--
Anahata
anahata(a)treewind.co.uk -+- http://www.treewind.co.uk
Home: 01638 720444 Mob: 07976 263827
8 Aug
8 Aug
4:01 p.m.
On Sat, 2004-08-07 at 22:51, Lee Revell wrote:
On Sun, 2004-08-08 at 01:28, Rick B wrote:
No yet. The 2.6.x for FC2 I have only has the lsm module (and a few
small latency patches from Takashi). I'm working on a newer version that
includes rc2-mm2 and the O3 version of the voluntary preemption patch.
-- Fernando
Is there any way to do this on a 2.4 kernel?
Like say,
2.4.26-ll.rhfc1.ccrma, or is this already covered with how Fernando
configures the kernel?
No, as the thread name implies, you need a recent 2.6 kernel with Ingo
Molnar's voluntary preemption patches to get these new features. I
believe CCRMA may have a 2.6.7+voluntary preempt package, but I don't
use it so I'm not sure.
8:06 a.m.
On Sun, 08 Aug 2004 00:41:36 -0400
Lee Revell <rlrevell(a)joe-job.com> wrote:
/proc/irq/10/EMU10K1/threaded
0
/proc/irq/10/uhci_hcd/threaded
1
Hi, afaik in this case uhci_hcd is non threaded, too, although the /proc
interface shows it differently. I think this should be fixed in O3 or
something?
Flo
--
Palimm Palimm!
http://affenbande.org/~tapas/
2:49 a.m.
On Sat, 2004-08-07 at 21:27, Lee Revell wrote:
In practice I have found that if I do not make the
rtc interrupt
non-threaded I get 'rtc: lost some interrupts at 1024 hz' messages when
using mplayer, and xruns in alsa unless i do the same for the sound
card.
Am i correct to assume that it's good to make the RTC IRQ non-threaded
when i want to achieve soft-realtime with any application, not
necessarily with JACK, not necessarily a multimedia app?
--
Florin Andrei
http://florin.myip.org/
2:59 a.m.
On Sun, 2004-08-08 at 00:33, Florin Andrei wrote:
On Sat, 2004-08-07 at 21:27, Lee Revell wrote:
Not all of these will use it. mplayer uses it, and I believe someone
mentioned using it to send midi clock. It isn't used for general
timing, I believe the system timer interrupt (irq 0) is used for that.
I just enable it in my tests because it's likely to be enabled on a DAW,
but I don't think any of my current software uses it much.
Lee
In practice I have found that if I do not make
the rtc interrupt
non-threaded I get 'rtc: lost some interrupts at 1024 hz' messages when
using mplayer, and xruns in alsa unless i do the same for the sound
card.
Am i correct to assume that it's good to make the RTC IRQ non-threaded
when i want to achieve soft-realtime with any application, not
necessarily with JACK, not necessarily a multimedia app?
7554
days inactive
7563
days old
linux-audio-user@lists.linuxaudio.org
52 comments
12 participants
participants (12)
-
anahata -
Fernando Pablo Lopez-Lezcano -
Florian Schmidt -
Florin Andrei -
Jack O'Quin -
John Check -
Jonathan Segel -
Lee Revell -
Luke Yelavich -
Malcolm Baldridge -
Mark Knecht -
Rick B