7 Feb
2006
7 Feb
'06
11:54 a.m.
Hi all,
Could a better graphics card result in better realtime performance? I can
get a good realtime performance on my box (buffersize 64 and less) but
when using X some display activity seems to cause xruns. E.g sooperlooper
is far more usable without it's gui.
This is on a pentium3 600Mhz PC, running gentoo kernel 2.6.14 with rt22
patch applied. I also prioritize the irq's as documented on this list. The
graphics card is a Nvidia Vanta LT with 16 Mb memory.
Any thoughts?
--
regards,
gerrit
7 Feb
7 Feb
12:10 p.m.
On Tue, 2006-02-07 at 17:54 +0100, Gerrit Niestijl wrote:
Hi all,
Could a better graphics card result in better realtime performance? I can
get a good realtime performance on my box (buffersize 64 and less) but
when using X some display activity seems to cause xruns. E.g sooperlooper
is far more usable without it's gui.
This is on a pentium3 600Mhz PC, running gentoo kernel 2.6.14 with rt22
patch applied. I also prioritize the irq's as documented on this list. The
graphics card is a Nvidia Vanta LT with 16 Mb memory.
Are you using the proprietary Nvidia driver?
Lee
1:43 p.m.
On Tue, Feb 07, 2006 at 12:09:57PM -0500, Lee Revell wrote:
On Tue, 2006-02-07 at 17:54 +0100, Gerrit Niestijl
wrote:
No, i used to but they don't support my card anymore.
--
gerrit
Hi all,
Could a better graphics card result in better realtime performance? I can
get a good realtime performance on my box (buffersize 64 and less) but
when using X some display activity seems to cause xruns. E.g sooperlooper
is far more usable without it's gui.
This is on a pentium3 600Mhz PC, running gentoo kernel 2.6.14 with rt22
patch applied. I also prioritize the irq's as documented on this list. The
graphics card is a Nvidia Vanta LT with 16 Mb memory.
Are you using the proprietary Nvidia driver? 
3:36 p.m.
> get a good realtime performance on my box
(buffersize 64 and less) but
> when using X some display activity seems to cause xruns. E.g sooperlooper
ive had decent luck by renicing the X server to a lower priority (higher number) and doing
the opposite to jackd. depending on how your X is started (gdm, xdm, startx) the way to
nice it on launch may differ, but give it a shot..
im not sure 'top' can be trusted. for ex running ices doing a realtime ogg encode
takes 5-6% CPU , without X running, and as soon as X is launched, that number doubles,
according to top..
4:07 p.m.
On Tue, 2006-02-07 at 20:36 +0000, cdr wrote:
jackd and JACK clients should never be reniced, they uses RT thread
priorities which are more fine grained than nice values. This could
lead to incorrect behavior.
If your distro automatically runs X at nice -10 this should be disabled.
> get a
good realtime performance on my box (buffersize 64 and less) but
> when using X some display activity seems to cause xruns. E.g sooperlooper
ive had decent luck by renicing the X server to a lower priority (higher number) and
doing the opposite to jackd. depending on how your X is started (gdm, xdm, startx)
the way to nice it on launch may differ, but give it a shot..
im not sure 'top' can be trusted. for ex running ices doing a realtime ogg encode
takes 5-6% CPU ,
without X running, and as soon as X is launched, that
number doubles, according to top..
4:06 p.m.
On Tue, 7 Feb 2006 17:54:30 +0100 (CET)
"Gerrit Niestijl" <gn(a)hetnet.nl> wrote:
Hi all,
Could a better graphics card result in better realtime performance? I can
get a good realtime performance on my box (buffersize 64 and less) but
when using X some display activity seems to cause xruns. E.g sooperlooper
is far more usable without it's gui.
This is on a pentium3 600Mhz PC, running gentoo kernel 2.6.14 with rt22
patch applied. I also prioritize the irq's as documented on this list. The
graphics card is a Nvidia Vanta LT with 16 Mb memory.
What software do you use? I assume JACK? If so, setting up the irq's is
not enough. You also need to run jackd with the right prio (below
soundcard irq, but above all others)
See
http://tapas.affenbande.org/?page_id=40
for a little more exhaustive info.
Regards,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
8 Feb
8 Feb
3:50 p.m.
On Tue, Feb 07, 2006 at 10:06:46PM +0100, Florian Schmidt wrote:
Yes, i use jack. I also use the rtirq package. Here is the relevant
info:
reus ~ # cat /proc/interrupts
CPU0
0: 1009634 XT-PIC [........N/ 0] pit
1: 727 XT-PIC [........./ 0] i8042
2: 0 XT-PIC [........N/ 0] cascade
4: 0 XT-PIC [........./ 0] Serial MIDI
5: 1661 XT-PIC [........./ 0] eth0
8: 2 XT-PIC [........./ 0] rtc
9: 1 XT-PIC [........./ 0] acpi, ICE1712
10: 121 XT-PIC [........./ 0] uhci_hcd:usb1, EMU10K1
12: 3651 XT-PIC [........./ 0] i8042
14: 4926 XT-PIC [........./ 0] ide0
15: 653 XT-PIC [........./ 0] ide1
reus ~ # /etc/init.d/rtirq status
* status: started
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
200 FF 80 - 120 0.0 S< IRQ 8
14 FF 70 - 110 0.0 S< IRQ 9
262 FF 60 - 100 0.0 S< IRQ 10
277 FF 50 - 90 0.0 S< IRQ 1
206 FF 49 - 89 0.0 S< IRQ 12
209 FF 46 - 86 0.0 S< IRQ 6
240 FF 45 - 85 0.0 S< IRQ 14
242 FF 44 - 84 0.0 S< IRQ 15
6472 FF 41 - 81 0.0 S< IRQ 5
6635 FF 40 - 80 0.0 S< IRQ 4
Not exactly the same numbers as yours, but it looks ok to me.
I was trying to avoid the route Lee mentions, debugging using the
latency tracer, but it looks like i have to find some time to study
it. Anyway, thanks a lot all of you for your input, i will let you know
when i have made some progress.
--
gerrit
Hi all,
Could a better graphics card result in better realtime performance? I can
get a good realtime performance on my box (buffersize 64 and less) but
when using X some display activity seems to cause xruns. E.g sooperlooper
is far more usable without it's gui.
This is on a pentium3 600Mhz PC, running gentoo kernel 2.6.14 with rt22
patch applied. I also prioritize the irq's as documented on this list. The
graphics card is a Nvidia Vanta LT with 16 Mb memory.
What software do you use? I assume JACK? If so, setting up the irq's is
not enough. You also need to run jackd with the right prio (below
soundcard irq, but above all others)
See
http://tapas.affenbande.org/?page_id=40
for a little more exhaustive info. 
10 Feb
10 Feb
6:53 a.m.
Gerrit Niestijl escribe:
9: 1 XT-PIC [........./ 0] acpi,
ICE1712
10: 121 XT-PIC [........./ 0] uhci_hcd:usb1, EMU10K1
I would never share a soundcard's IRQ with ACPI's, I'd force IRQ 10
for my main soundcard. Just a thought.
Cordially, Ismael
--
Dropping science like when Galileo dropped his orange
http://lamediahostia.blogspot.com/
http://www.flickr.com/photos/ivalladt/
12:45 p.m.
On Fri, 2006-02-10 at 12:53 +0100, Ismael Valladolid Torres wrote:
Gerrit Niestijl escribe:
Should not matter, ACPI IRQs are rare.
Lee
9: 1 XT-PIC [........./ 0]
acpi, ICE1712
10: 121 XT-PIC [........./ 0] uhci_hcd:usb1, EMU10K1
I would never share a soundcard's IRQ with ACPI's, I'd force IRQ 10
for my main soundcard. Just a thought.
7 Feb
7 Feb
4:39 p.m.
On Tue, 2006-02-07 at 17:54 +0100, Gerrit Niestijl wrote:
Hi all,
Could a better graphics card result in better realtime performance? I can
get a good realtime performance on my box (buffersize 64 and less) but
when using X some display activity seems to cause xruns. E.g sooperlooper
is far more usable without it's gui.
This is on a pentium3 600Mhz PC, running gentoo kernel 2.6.14 with rt22
patch applied. I also prioritize the irq's as documented on this list. The
graphics card is a Nvidia Vanta LT with 16 Mb memory.
Any thoughts?
The only reliable way to debug this stuff is with the latency tracer
(see the list archives for details).
Lee
11 Feb
11 Feb
10:18 a.m.
The only reliable way to debug this stuff is with the
latency tracer
(see the list archives for details).
Here is a latency trace. I started sooperlooper with it's gui and loaded
a loop. After a fem minutes some xruns occur that throw sooperlooper out
of jack. The trace is from immediately after this. Does this reveal
anything?
gerrit
preemption latency trace v1.1.5 on 2.6.14-rt22-debugy
--------------------------------------------------------------------
latency: 89 us, #64/64, CPU#0 | (M:rt VP:0, KP:0, SP:1 HP:1)
-----------------
| task: softirq-timer/0-3 (uid:0 nice:0 policy:1 rt_prio:1)
-----------------
_------=> CPU#
/ _-----=> irqs-off
| / _----=> need-resched
|| / _---=> hardirq/softirq
||| / _--=> preempt-depth
|||| /
||||| delay
cmd pid ||||| time | caller
\ / ||||| \ | /
sooperlo-5783 0D... 1us : common_interrupt ((0))
sooperlo-5783 0D.h. 3us+: do_IRQ (80713f8 0 0)
sooperlo-5783 0D.h1 6us+: mask_and_ack_8259A (__do_IRQ)
sooperlo-5783 0D.h1 12us+: redirect_hardirq (__do_IRQ)
sooperlo-5783 0D.h. 14us : handle_IRQ_event (__do_IRQ)
sooperlo-5783 0D.h. 16us : timer_interrupt (handle_IRQ_event)
sooperlo-5783 0D.h. 17us : io_apic_timer_ack (timer_interrupt)
sooperlo-5783 0D.h. 18us : handle_tick_update (timer_interrupt)
sooperlo-5783 0D.h1 20us : do_timer (handle_tick_update)
sooperlo-5783 0D.h. 21us : update_process_times (handle_tick_update)
sooperlo-5783 0D.h. 22us : account_user_time (update_process_times)
sooperlo-5783 0D.h. 23us : run_local_timers (update_process_times)
sooperlo-5783 0D.h. 25us : raise_softirq (run_local_timers)
sooperlo-5783 0D.h. 26us+: wakeup_softirqd (raise_softirq)
sooperlo-5783 0D.h. 28us : wake_up_process (wakeup_softirqd)
sooperlo-5783 0D.h. 29us+: try_to_wake_up (wake_up_process)
sooperlo-5783 0D.h1 31us : activate_task (try_to_wake_up)
sooperlo-5783 0D.h1 31us : sched_clock (activate_task)
sooperlo-5783 0D.h1 33us+: recalc_task_prio (activate_task)
sooperlo-5783 0D.h1 36us : __recalc_task_prio (recalc_task_prio)
sooperlo-5783 0D.h1 37us : __recalc_task_prio <<...>-3> (62 62)
sooperlo-5783 0D.h1 38us : activate_task <<...>-3> (62 7)
sooperlo-5783 0D.h1 39us+: enqueue_task (activate_task)
sooperlo-5783 0Dnh1 41us : try_to_wake_up <<...>-3> (62 74)
sooperlo-5783 0Dnh. 42us : preempt_schedule (try_to_wake_up)
sooperlo-5783 0Dnh. 43us : wake_up_process (wakeup_softirqd)
sooperlo-5783 0Dnh. 44us : rcu_pending (update_process_times)
sooperlo-5783 0Dnh. 46us : scheduler_tick (update_process_times)
sooperlo-5783 0Dnh. 47us+: sched_clock (scheduler_tick)
sooperlo-5783 0Dnh1 49us+: task_timeslice (scheduler_tick)
sooperlo-5783 0Dnh. 51us+: preempt_schedule (scheduler_tick)
sooperlo-5783 0Dnh1 53us : note_interrupt (__do_IRQ)
sooperlo-5783 0Dnh1 55us+: enable_8259A_irq (__do_IRQ)
sooperlo-5783 0Dnh1 57us : preempt_schedule (enable_8259A_irq)
sooperlo-5783 0Dnh. 57us : preempt_schedule (__do_IRQ)
sooperlo-5783 0Dnh. 58us : irq_exit (do_IRQ)
sooperlo-5783 0Dn.. 59us : __schedule (work_resched)
sooperlo-5783 0Dn.. 60us : profile_hit (__schedule)
sooperlo-5783 0Dn.1 60us+: sched_clock (__schedule)
<...>-3 0D..2 65us+: __switch_to (__schedule)
<...>-3 0D..2 68us : __schedule <sooperlo-5783> (74 62)
<...>-3 0D.h2 70us : do_IRQ (c039a4f4 9 0)
<...>-3 0D.h3 71us+: mask_and_ack_8259A (__do_IRQ)
<...>-3 0D.h3 78us : redirect_hardirq (__do_IRQ)
<...>-3 0D.h3 79us : wake_up_process (redirect_hardirq)
<...>-3 0D.h3 79us : try_to_wake_up (wake_up_process)
<...>-3 0D.h4 80us : activate_task (try_to_wake_up)
<...>-3 0D.h4 80us : sched_clock (activate_task)
<...>-3 0D.h4 80us : recalc_task_prio (activate_task)
<...>-3 0D.h4 81us : __recalc_task_prio (recalc_task_prio)
<...>-3 0D.h4 82us : __recalc_task_prio <<...>-14> (1d 1d)
<...>-3 0D.h4 82us : activate_task <<...>-14> (1d 8)
<...>-3 0D.h4 83us : enqueue_task (activate_task)
<...>-3 0Dnh4 83us : try_to_wake_up <<...>-14> (1d 62)
<...>-3 0Dnh3 84us : preempt_schedule (try_to_wake_up)
<...>-3 0Dnh3 84us : wake_up_process (redirect_hardirq)
<...>-3 0Dnh2 84us : preempt_schedule (__do_IRQ)
<...>-3 0Dnh2 85us : irq_exit (do_IRQ)
<...>-3 0Dn.2 85us < (608)
<...>-3 0.n.1 87us : preempt_schedule (__schedule)
<...>-3 0.n.1 87us : sub_preempt_count (__schedule)
<...>-3 0.n.1 89us : sub_preempt_count_ti (sub_preempt_count)
vim:ft=help
2:26 p.m.
On Sat, 2006-02-11 at 16:18 +0100, Gerrit Niestijl wrote:
Your maximum kernel-induced latency is less than 0.1ms - this
demonstrates that the problem is in one of your apps, not the kernel.
Probably Sooperlooper does something that's not RT safe in it's
process() callback.
In order to find the bug in your JACK clients you can use the "user
triggered latency tracing" feature of the -rt kernel (see list archive).
Lee
The only
reliable way to debug this stuff is with the latency tracer
(see the list archives for details).
Here is a latency trace. I started sooperlooper with it's gui and loaded
a loop. After a fem minutes some xruns occur that throw sooperlooper out
of jack. The trace is from immediately after this. Does this reveal
anything?
gerrit
preemption latency trace v1.1.5 on 2.6.14-rt22-debugy
--------------------------------------------------------------------
latency: 89 us, #64/64, CPU#0 | (M:rt VP:0, KP:0, SP:1 HP:1)
7007
days inactive
7011
days old
linux-audio-user@lists.linuxaudio.org
12 comments
5 participants
participants (5)
-
cdr -
Florian Schmidt -
Gerrit Niestijl -
Ismael Valladolid Torres -
Lee Revell