suddenly seeking xruns

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

suddenly seeking xruns

LGTrader
Hi,
   On the new AMD64 machine I went along for the first week or two
without (I think) any xruns. Suddently in the last two days they are
running rampant. I did build a new kernel to include a couple of
features supposedly required for UTF-8 support, but other than that no
changes that I am aware of.

   Additionally I built Ardour-beta30 but this is happening without
Ardour runnign so I doubt that's involved.

   I am currently building some code in the background, but in the
past it was my observation that this didn't matter. Maybe I was wrong.

   I beleive Jack is running from memory and not from disk. From fstab
I have this which was placed there by Gentoo's install process:

shm                     /dev/shm        tmpfs          
nodev,nosuid,noexec    0 0

Here's what I'm seeing:

apparent rate = 44100
creating alsa driver ... hw:1|hw:1|256|2|44100|0|0|nomon|swmeter|-|32bit
control device hw:1
configuring for 44100Hz, period = 256 frames, buffer = 2 periods
nperiods = 2 for capture
nperiods = 2 for playback
07:50:03.499 Server configuration saved to "/home/mark/.jackdrc".
07:50:03.499 Statistics reset.
07:50:03.642 Client activated.
07:50:03.644 Audio connection change.
07:50:03.647 Audio connection graph change.
10:04:16.155 Audio connection graph change.
10:04:16.334 Audio connection change.
10:04:17.942 Audio connection graph change.
subgraph starting at qjackctl-7767 timed out (subgraph_wait_fd=17,
status = 0, state = Finished)
10:04:22.950 XRUN callback (1).
**** alsa_pcm: xrun of at least 1.116 msecs
**** alsa_pcm: xrun of at least 6.907 msecs
10:04:23.165 XRUN callback (1 skipped).
10:20:41.179 XRUN callback (3).
**** alsa_pcm: xrun of at least 168.039 msecs
10:21:01.060 XRUN callback (4).
**** alsa_pcm: xrun of at least 50.610 msecs
10:21:06.104 XRUN callback (5).
**** alsa_pcm: xrun of at least 91.528 msecs
10:21:11.443 XRUN callback (6).
**** alsa_pcm: xrun of at least 433.811 msecs
10:21:16.462 XRUN callback (7).
**** alsa_pcm: xrun of at least 449.423 msecs
10:21:21.523 XRUN callback (8).
**** alsa_pcm: xrun of at least 508.938 msecs
10:21:42.133 XRUN callback (9).
**** alsa_pcm: xrun of at least 123.750 msecs
10:21:57.077 XRUN callback (10).
**** alsa_pcm: xrun of at least 64.414 msecs
10:22:02.684 XRUN callback (11).
**** alsa_pcm: xrun of at least 672.416 msecs
10:24:36.442 XRUN callback (12).
**** alsa_pcm: xrun of at least 430.147 msecs
10:50:20.015 XRUN callback (13).
**** alsa_pcm: xrun of at least 3.961 msecs
11:00:16.436 XRUN callback (14).
**** alsa_pcm: xrun of at least 426.624 msecs
11:00:26.292 XRUN callback (15).
**** alsa_pcm: xrun of at least 283.217 msecs
11:00:36.379 XRUN callback (16).
**** alsa_pcm: xrun of at least 368.456 msecs

Not good results, especially at 256/2 and using an HDSP 9652. Disappointing.

Any ideas where I should start looking? I'm seeing that running hdparm
-tT /dev/sda is causing xruns also.

Thanks,
Mark


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: suddenly seeking xruns

Lee Revell
On Fri, 2005-09-16 at 11:08 -0700, Mark Knecht wrote:
> Hi,
>    On the new AMD64 machine I went along for the first week or two
> without (I think) any xruns. Suddently in the last two days they are
> running rampant. I did build a new kernel to include a couple of
> features supposedly required for UTF-8 support, but other than that no
> changes that I am aware of.

What kernel version?  If it's an RT kernel then enable latency tracing
and check /proc/latency_trace.

Lee



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: suddenly seeking xruns

David Mulcahy
In reply to this post by LGTrader
On Friday 16 September 2005 19:08, Mark Knecht wrote:

> Hi,
>    On the new AMD64 machine I went along for the first week or two
> without (I think) any xruns. Suddently in the last two days they are
> running rampant. I did build a new kernel to include a couple of
> features supposedly required for UTF-8 support, but other than that no
> changes that I am aware of.
>
>    Additionally I built Ardour-beta30 but this is happening without
> Ardour runnign so I doubt that's involved.
>
>    I am currently building some code in the background, but in the
> past it was my observation that this didn't matter. Maybe I was wrong.
>
>    I beleive Jack is running from memory and not from disk. From fstab
> I have this which was placed there by Gentoo's install process:
>
Try removing this line bellow from fstab
> shm                     /dev/shm        tmpfs
with recent glibc (I think) this gets done automatically at boot time and
someone reported a while back now that mounting this twice (which might be
what is happening in your case) actually caused xruns.

HTH Dave



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: suddenly seeking xruns

LGTrader
In reply to this post by Lee Revell
On 9/16/05, Lee Revell <[hidden email]> wrote:

> On Fri, 2005-09-16 at 11:08 -0700, Mark Knecht wrote:
> > Hi,
> >    On the new AMD64 machine I went along for the first week or two
> > without (I think) any xruns. Suddently in the last two days they are
> > running rampant. I did build a new kernel to include a couple of
> > features supposedly required for UTF-8 support, but other than that no
> > changes that I am aware of.
>
> What kernel version?  If it's an RT kernel then enable latency tracing
> and check /proc/latency_trace.
>
> Lee
>
>
Sorry Lee. I should have included that sort of stuff:

mark@lightning ~ $ uname -a
Linux lightning 2.6.13-gentoo #6 Thu Sep 15 16:18:00 PDT 2005 x86_64
AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux
mark@lightning ~ $

Does this qualify as RT? It's all I've been doing for the last year
running the same card on an Athl0n-XP at 128/2 most of the time:

      Processor family (AMD-Opteron/Athlon64)  --->
  │ │  < > /dev/cpu/microcode - Intel CPU microcode support
  │ │  <*> /dev/cpu/*/msr - Model-specific register support
  │ │  <*> /dev/cpu/*/cpuid - CPU information support
  │ │  [*] MTRR (Memory Type Range Register) support
  │ │  [ ] Symmetric multi-processing support
  │ │      Preemption Model (Preemptible Kernel (Low-Latency Desktop))  --->
  │ │  [*] Preempt The Big Kernel Lock
  │ │      Memory model (Flat Memory)  --->
  │ │  [*] PM timer
  │ │  [*] Provide RTC interrupt
  │ │  [*] IOMMU support
  │ │  --- Machine check support
  │ │  [*]   Intel MCE features
  │ │  [ ] kexec system call (EXPERIMENTAL)
  │ │  [*] Enable seccomp to safely compute untrusted bytecode
  │ │      Timer frequency (1000 HZ)  --->

Under Kernel Hacking I have this:

    [*]   Debug preemptible kernel    

Where do I find 'latency tracing'? I do not have /proc/latency_trace
HS^╣И ┼X╛╡ '╡┼чu╪⌠jg╡╒ЙщzВ╔╒≥··в!jY^·╛б+a√°┘Кz╨'┼j╕■·╝В╚▄'√├²┼вХ╜Зчy╘щmГ╖╣Йчvз0┼v╦з≥Z╡f╜╬┼Р╒ЙОz╪╗бt╗÷+f=#б√'$┘Йч╤┼ek(m╤÷Ъ╡▀╚qГХ╝╖zъЮz╨'┼j)├▓ZrH╜uКч√f╒√)Ю√+-%╖$┼в^╫Иe┼кl╡▀╚qГХ╝╖zьm╤⌡?ЧX╛╤к(╨╥~┼Юzw╜ЧX╛╤оЕ┼кb²З?█╖$┼в^╫И
Reply | Threaded
Open this post in threaded view
|

Re: suddenly seeking xruns

Lee Revell
On Fri, 2005-09-16 at 12:17 -0700, Mark Knecht wrote:

> On 9/16/05, Lee Revell <[hidden email]> wrote:
> > On Fri, 2005-09-16 at 11:08 -0700, Mark Knecht wrote:
> > > Hi,
> > >    On the new AMD64 machine I went along for the first week or two
> > > without (I think) any xruns. Suddently in the last two days they are
> > > running rampant. I did build a new kernel to include a couple of
> > > features supposedly required for UTF-8 support, but other than that no
> > > changes that I am aware of.
> >
> > What kernel version?  If it's an RT kernel then enable latency tracing
> > and check /proc/latency_trace.
> >
> > Lee
> >
> >
> Sorry Lee. I should have included that sort of stuff:
>
> mark@lightning ~ $ uname -a
> Linux lightning 2.6.13-gentoo #6 Thu Sep 15 16:18:00 PDT 2005 x86_64
> AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux
> mark@lightning ~ $
>
> Does this qualify as RT? It's all I've been doing for the last year
> running the same card on an Athl0n-XP at 128/2 most of the time:
>
>       Processor family (AMD-Opteron/Athlon64)  --->
>   │ │  < > /dev/cpu/microcode - Intel CPU microcode support
>   │ │  <*> /dev/cpu/*/msr - Model-specific register support
>   │ │  <*> /dev/cpu/*/cpuid - CPU information support
>   │ │  [*] MTRR (Memory Type Range Register) support
>   │ │  [ ] Symmetric multi-processing support
>   │ │      Preemption Model (Preemptible Kernel (Low-Latency Desktop))  --->
>   │ │  [*] Preempt The Big Kernel Lock
>   │ │      Memory model (Flat Memory)  --->
>   │ │  [*] PM timer
>   │ │  [*] Provide RTC interrupt
>   │ │  [*] IOMMU support
>   │ │  --- Machine check support
>   │ │  [*]   Intel MCE features
>   │ │  [ ] kexec system call (EXPERIMENTAL)
>   │ │  [*] Enable seccomp to safely compute untrusted bytecode
>   │ │      Timer frequency (1000 HZ)  --->
>
> Under Kernel Hacking I have this:
>
>     [*]   Debug preemptible kernel    
>
> Where do I find 'latency tracing'? I do not have /proc/latency_trace

Apply this patch to your kernel:

http://redhat.com/~mingo/realtime-preempt/patch-2.6.13-rt12

Run "make oldconfig" and enable these debug options:

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
# CONFIG_PRINTK_IGNORE_LOGLEVEL is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_MAGIC_SYSRQ is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_DETECT_SOFTLOCKUP is not set
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
CONFIG_DEBUG_PREEMPT=y
CONFIG_DEBUG_IRQ_FLAGS=y
CONFIG_WAKEUP_TIMING=y
# CONFIG_WAKEUP_LATENCY_HIST is not set
CONFIG_PREEMPT_TRACE=y
CONFIG_CRITICAL_PREEMPT_TIMING=y
# CONFIG_PREEMPT_OFF_HIST is not set
CONFIG_CRITICAL_IRQSOFF_TIMING=y
# CONFIG_INTERRUPT_OFF_HIST is not set
CONFIG_CRITICAL_TIMING=y
CONFIG_LATENCY_TIMING=y
CONFIG_LATENCY_TRACE=y
CONFIG_MCOUNT=y
# CONFIG_RT_DEADLOCK_DETECT is not set
# CONFIG_DEBUG_RT_LOCKING_MODE is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_FS is not set
CONFIG_FRAME_POINTER=y
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_KPROBES is not set
# CONFIG_DEBUG_STACK_USAGE is not set

Make sure to DISABLE "High Res Timers", it's experimental code.

Then recompile the kernel and you can use /proc/latency_trace to
identify the problem.

Lee



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: suddenly seeking xruns

LGTrader
Lee,
   Thanks. I'll give it a shot. If it doesn't apply vs. the Gentoo
kernel then I guess I'll try kernel.org.

   In the meantine I've not had an xrun since 11:30AM. It's 2PM now. I
was building code through portage so that's CPU, disk and network
activity. Since that finished I've continued to use the network, but
CPU and disk activity has been fairly low. No xruns...

   Thanks for the patch pointer.

Cheers,
Mark

On 9/16/05, Lee Revell <[hidden email]> wrote:

> On Fri, 2005-09-16 at 12:17 -0700, Mark Knecht wrote:
> > On 9/16/05, Lee Revell <[hidden email]> wrote:
> > > On Fri, 2005-09-16 at 11:08 -0700, Mark Knecht wrote:
> > > > Hi,
> > > >    On the new AMD64 machine I went along for the first week or two
> > > > without (I think) any xruns. Suddently in the last two days they are
> > > > running rampant. I did build a new kernel to include a couple of
> > > > features supposedly required for UTF-8 support, but other than that no
> > > > changes that I am aware of.
> > >
> > > What kernel version?  If it's an RT kernel then enable latency tracing
> > > and check /proc/latency_trace.
> > >
> > > Lee
> > >
> > >
> > Sorry Lee. I should have included that sort of stuff:
> >
> > mark@lightning ~ $ uname -a
> > Linux lightning 2.6.13-gentoo #6 Thu Sep 15 16:18:00 PDT 2005 x86_64
> > AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux
> > mark@lightning ~ $
> >
> > Does this qualify as RT? It's all I've been doing for the last year
> > running the same card on an Athl0n-XP at 128/2 most of the time:
> >
> >       Processor family (AMD-Opteron/Athlon64)  --->
> >   │ │  < > /dev/cpu/microcode - Intel CPU microcode support
> >   │ │  <*> /dev/cpu/*/msr - Model-specific register support
> >   │ │  <*> /dev/cpu/*/cpuid - CPU information support
> >   │ │  [*] MTRR (Memory Type Range Register) support
> >   │ │  [ ] Symmetric multi-processing support
> >   │ │      Preemption Model (Preemptible Kernel (Low-Latency Desktop))  --->
> >   │ │  [*] Preempt The Big Kernel Lock
> >   │ │      Memory model (Flat Memory)  --->
> >   │ │  [*] PM timer
> >   │ │  [*] Provide RTC interrupt
> >   │ │  [*] IOMMU support
> >   │ │  --- Machine check support
> >   │ │  [*]   Intel MCE features
> >   │ │  [ ] kexec system call (EXPERIMENTAL)
> >   │ │  [*] Enable seccomp to safely compute untrusted bytecode
> >   │ │      Timer frequency (1000 HZ)  --->
> >
> > Under Kernel Hacking I have this:
> >
> >     [*]   Debug preemptible kernel
> >
> > Where do I find 'latency tracing'? I do not have /proc/latency_trace
>
> Apply this patch to your kernel:
>
> http://redhat.com/~mingo/realtime-preempt/patch-2.6.13-rt12
>
> Run "make oldconfig" and enable these debug options:
>
> #
> # Kernel hacking
> #
> # CONFIG_PRINTK_TIME is not set
> # CONFIG_PRINTK_IGNORE_LOGLEVEL is not set
> CONFIG_DEBUG_KERNEL=y
> # CONFIG_MAGIC_SYSRQ is not set
> CONFIG_LOG_BUF_SHIFT=14
> # CONFIG_DETECT_SOFTLOCKUP is not set
> # CONFIG_SCHEDSTATS is not set
> # CONFIG_DEBUG_SLAB is not set
> CONFIG_DEBUG_PREEMPT=y
> CONFIG_DEBUG_IRQ_FLAGS=y
> CONFIG_WAKEUP_TIMING=y
> # CONFIG_WAKEUP_LATENCY_HIST is not set
> CONFIG_PREEMPT_TRACE=y
> CONFIG_CRITICAL_PREEMPT_TIMING=y
> # CONFIG_PREEMPT_OFF_HIST is not set
> CONFIG_CRITICAL_IRQSOFF_TIMING=y
> # CONFIG_INTERRUPT_OFF_HIST is not set
> CONFIG_CRITICAL_TIMING=y
> CONFIG_LATENCY_TIMING=y
> CONFIG_LATENCY_TRACE=y
> CONFIG_MCOUNT=y
> # CONFIG_RT_DEADLOCK_DETECT is not set
> # CONFIG_DEBUG_RT_LOCKING_MODE is not set
> # CONFIG_DEBUG_KOBJECT is not set
> CONFIG_DEBUG_BUGVERBOSE=y
> # CONFIG_DEBUG_INFO is not set
> # CONFIG_DEBUG_FS is not set
> CONFIG_FRAME_POINTER=y
> CONFIG_EARLY_PRINTK=y
> # CONFIG_DEBUG_STACKOVERFLOW is not set
> # CONFIG_KPROBES is not set
> # CONFIG_DEBUG_STACK_USAGE is not set
>
> Make sure to DISABLE "High Res Timers", it's experimental code.
>
> Then recompile the kernel and you can use /proc/latency_trace to
> identify the problem.
>
> Lee
>
>
HS^╣И ┼X╛╡ '╡┼чu╪⌠jg╡╒ЙщzВ╔╒≥··в!jY^·╛б+a√°┘Кz╨'┼j╕■·╝В╚▄'√├²┼вХ╜Зчy╘щmГ╖╣Йчvз0┼v╦з≥Z╡f╜╬┼Р╒ЙОz╪╗бt╗÷+f=#б√'$┘Йч╤┼ek(m╤÷Ъ╡▀╚qГХ╝╖zъЮz╨'┼j)├▓ZrH╜uКч√f╒√)Ю√+-%╖$┼в^╫Иe┼кl╡▀╚qГХ╝╖zьm╤⌡?ЧX╛╤к(╨╥~┼Юzw╜ЧX╛╤оЕ┼кb²З?█╖$┼в^╫И
Reply | Threaded
Open this post in threaded view
|

Re: suddenly seeking xruns

Lee Revell
On Fri, 2005-09-16 at 14:03 -0700, Mark Knecht wrote:

> Lee,
>    Thanks. I'll give it a shot. If it doesn't apply vs. the Gentoo
> kernel then I guess I'll try kernel.org.
>
>    In the meantine I've not had an xrun since 11:30AM. It's 2PM now. I
> was building code through portage so that's CPU, disk and network
> activity. Since that finished I've continued to use the network, but
> CPU and disk activity has been fairly low. No xruns...
>
>    Thanks for the patch pointer.

It's probably the disk activity that leads to the xruns.  What
filesystem(s) are you using?

Lee



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: suddenly seeking xruns

LGTrader
On 9/16/05, Lee Revell <[hidden email]> wrote:

> On Fri, 2005-09-16 at 14:03 -0700, Mark Knecht wrote:
> > Lee,
> >    Thanks. I'll give it a shot. If it doesn't apply vs. the Gentoo
> > kernel then I guess I'll try kernel.org.
> >
> >    In the meantine I've not had an xrun since 11:30AM. It's 2PM now. I
> > was building code through portage so that's CPU, disk and network
> > activity. Since that finished I've continued to use the network, but
> > CPU and disk activity has been fairly low. No xruns...
> >
> >    Thanks for the patch pointer.
>
> It's probably the disk activity that leads to the xruns.  What
> filesystem(s) are you using?
>
> Lee

EIDE/ext3 as always for the system. That's where the compiles were
taking place. I also have a 1394/ext3 disk being used for
low-bandwidth off audio playback at the same time. Possibly the
NForce4 EIDE drivers aren't quite up to snuff yet, or maybe it's some
AMD64 specific issue with them?

I did solve an xrun problem for another NVidia/Ardour user where we
found his xruns were being caused by his network adapter. We had
compiled it with some extra groovy 'go-fast' option turned on. We
removed the option and the xruns went away. So far on my box I haven't
spotted any similar options yet but will look again.

- Mark


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: suddenly seeking xruns

Lee Revell
On Fri, 2005-09-16 at 14:29 -0700, Mark Knecht wrote:

> On 9/16/05, Lee Revell <[hidden email]> wrote:
> > On Fri, 2005-09-16 at 14:03 -0700, Mark Knecht wrote:
> > > Lee,
> > >    Thanks. I'll give it a shot. If it doesn't apply vs. the Gentoo
> > > kernel then I guess I'll try kernel.org.
> > >
> > >    In the meantine I've not had an xrun since 11:30AM. It's 2PM now. I
> > > was building code through portage so that's CPU, disk and network
> > > activity. Since that finished I've continued to use the network, but
> > > CPU and disk activity has been fairly low. No xruns...
> > >
> > >    Thanks for the patch pointer.
> >
> > It's probably the disk activity that leads to the xruns.  What
> > filesystem(s) are you using?
> >
> > Lee
>
> EIDE/ext3 as always for the system. That's where the compiles were
> taking place. I also have a 1394/ext3 disk being used for
> low-bandwidth off audio playback at the same time. Possibly the
> NForce4 EIDE drivers aren't quite up to snuff yet, or maybe it's some
> AMD64 specific issue with them?
>
> I did solve an xrun problem for another NVidia/Ardour user where we
> found his xruns were being caused by his network adapter. We had
> compiled it with some extra groovy 'go-fast' option turned on. We
> removed the option and the xruns went away. So far on my box I haven't
> spotted any similar options yet but will look again.
>

If you have the time and the inclination, it would be VERY helpful for
the kernel developers if, anytime you discover some random thing that
causes xruns, you could get /proc/latency_trace output or report the
exact workaround you used.  They are serious about low latency these
days and consider these to be bugs.

If you start getting the xruns again, see if unmounting/removing the
1394 disk helps at all.  I know that USB storage is or was bad for low
latency as it disables interrupts for long periods, possibly firewire
has a similar problem.

Also, make sure to compile the RT kernel with the same preemption mode
(CONFIG_PREEMPT and not PREEMPT_RT) you got the xruns with.  When you
boot the RT kernel, do:

echo 0 > /proc/sys/kernel/preempt_max_latency

to reset the counter.  Then try to reproduce the xruns.

Lee



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: suddenly seeking xruns

LGTrader
On 9/16/05, Lee Revell <[hidden email]> wrote:

> On Fri, 2005-09-16 at 14:29 -0700, Mark Knecht wrote:
> > On 9/16/05, Lee Revell <[hidden email]> wrote:
> > > On Fri, 2005-09-16 at 14:03 -0700, Mark Knecht wrote:
> > > > Lee,
> > > >    Thanks. I'll give it a shot. If it doesn't apply vs. the Gentoo
> > > > kernel then I guess I'll try kernel.org.
> > > >
> > > >    In the meantine I've not had an xrun since 11:30AM. It's 2PM now. I
> > > > was building code through portage so that's CPU, disk and network
> > > > activity. Since that finished I've continued to use the network, but
> > > > CPU and disk activity has been fairly low. No xruns...
> > > >
> > > >    Thanks for the patch pointer.
> > >
> > > It's probably the disk activity that leads to the xruns.  What
> > > filesystem(s) are you using?
> > >
> > > Lee
> >
> > EIDE/ext3 as always for the system. That's where the compiles were
> > taking place. I also have a 1394/ext3 disk being used for
> > low-bandwidth off audio playback at the same time. Possibly the
> > NForce4 EIDE drivers aren't quite up to snuff yet, or maybe it's some
> > AMD64 specific issue with them?
> >
> > I did solve an xrun problem for another NVidia/Ardour user where we
> > found his xruns were being caused by his network adapter. We had
> > compiled it with some extra groovy 'go-fast' option turned on. We
> > removed the option and the xruns went away. So far on my box I haven't
> > spotted any similar options yet but will look again.
> >
>
> If you have the time and the inclination, it would be VERY helpful for
> the kernel developers if, anytime you discover some random thing that
> causes xruns, you could get /proc/latency_trace output or report the
> exact workaround you used.  They are serious about low latency these
> days and consider these to be bugs.

OK. Very happy to help. I'm hoping I can get back to a place where a
straight Gentoo kernel works well enough so I don't have to patch. My
ATI laptop and my Via desktop have both been great. This is my first
AMD64 and my first NVidia chipset.

>
> If you start getting the xruns again, see if unmounting/removing the
> 1394 disk helps at all.  I know that USB storage is or was bad for low
> latency as it disables interrupts for long periods, possibly firewire
> has a similar problem.

I found that doing hdparm -tT on either the internal EIDE or the 1394
drive would cause maybe one or two xruns over the length of the test,
which is a short time. Seems like that must be part of the problem.

>
> Also, make sure to compile the RT kernel with the same preemption mode
> (CONFIG_PREEMPT and not PREEMPT_RT) you got the xruns with.  When you
> boot the RT kernel, do:
>
> echo 0 > /proc/sys/kernel/preempt_max_latency
>
> to reset the counter.  Then try to reproduce the xruns.
>
> Lee
>
>

Will do. I'll see if I get info that makes sense to me or whether I
need to ask more about running the tools.

The patch isn't perfect against the Gentoo kernel:

lightning linux # patch -p1 --dry-run </home/mark/patch-2.6.13-rt12
>/home/mark/dry-run.txt
patching file Documentation/RCU/proc.txt
patching file MAINTAINERS
patching file Makefile
Hunk #1 FAILED at 1.
1 out of 2 hunks FAILED -- saving rejects to file Makefile.rej
patching file arch/arm/mach-pxa/corgi_ssp.c
patching file arch/i386/Kconfig

<SNIP>

patching file drivers/video/backlight/corgi_bl.c
patching file drivers/video/console/fbcon.c
Hunk #1 succeeded at 1057 (offset 10 lines).
Hunk #2 FAILED at 1085.
Hunk #3 succeeded at 2868 (offset 105 lines).
1 out of 3 hunks FAILED -- saving rejects to file
drivers/video/console/fbcon.c.rej
patching file drivers/video/console/vgacon.c
patching file drivers/video/fbmon.c

<SNIP>

Other than that just a few offset messages.

Probably I shouldn't bother with the Gentoo kernel unless we can
figure out these FAILED messages. If I shift to the kernel.org kernel
Ihave no idea if that has xruns so I'd have to test it first for a few
days.

- Mark


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: suddenly seeking xruns

Lee Revell
On Fri, 2005-09-16 at 16:00 -0700, Mark Knecht wrote:
> Probably I shouldn't bother with the Gentoo kernel unless we can
> figure out these FAILED messages. If I shift to the kernel.org kernel
> Ihave no idea if that has xruns so I'd have to test it first for a few
> days.

Try it anyway, it might work.

Lee



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: suddenly seeking xruns

Phil Frost
In reply to this post by LGTrader
On Fri, Sep 16, 2005 at 04:00:32PM -0700, Mark Knecht wrote:

>
> OK. Very happy to help. I'm hoping I can get back to a place where a
> straight Gentoo kernel works well enough so I don't have to patch. My
> ATI laptop and my Via desktop have both been great. This is my first
> AMD64 and my first NVidia chipset.
>
> I found that doing hdparm -tT on either the internal EIDE or the 1394
> drive would cause maybe one or two xruns over the length of the test,
> which is a short time. Seems like that must be part of the problem.
>
> ...

I have an nvidia chipset and amd64 as well. I have an sata hd, but
initially dma was not enabled for the ata cdrom. hdparm wouldn't let me
unable it until i did some combination of switching from linux 2.6.10 to
2.6.13 and put the nvidia chipset module to load first in /etc/modules;
hdparm would then allow me to enable dma but it wasn't on by default.
Perhaps you are having similar problems?

After all my tweaking, running 2.6.13 with realtime-preempt patches, I
was able to get latency down to about 8 ms but I still get occasional
streams of xruns, especially when starting programs. My soundcard is an
audigy 2 zs; the same card got about 2 ms in my old non-64 amd box.


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: suddenly seeking xruns

LGTrader
In reply to this post by Lee Revell
Hi Lee,
   I'm back to trying out new kernels with the realtime patches. By
the time I got there the newest was -14 so I tried that. Unfortunately
the kernel didn't compile:

  CC      arch/x86_64/lib/io.o
  LD      arch/x86_64/lib/built-in.o
  CC      arch/x86_64/lib/bitops.o
  CC      arch/x86_64/lib/bitstr.o
  AS      arch/x86_64/lib/clear_page.o
  AS      arch/x86_64/lib/copy_page.o
  AS      arch/x86_64/lib/copy_user.o
  AS      arch/x86_64/lib/csum-copy.o
  CC      arch/x86_64/lib/csum-partial.o
  CC      arch/x86_64/lib/csum-wrappers.o
  CC      arch/x86_64/lib/delay.o
  AS      arch/x86_64/lib/getuser.o
  AS      arch/x86_64/lib/memcpy.o
  CC      arch/x86_64/lib/memmove.o
  AS      arch/x86_64/lib/memset.o
  AS      arch/x86_64/lib/putuser.o
  AS      arch/x86_64/lib/thunk.o
  CC      arch/x86_64/lib/usercopy.o
  AR      arch/x86_64/lib/lib.a
  GEN     .version
  CHK     include/linux/compile.h
  UPD     include/linux/compile.h
  CC      init/version.o
  LD      init/built-in.o
  LD      .tmp_vmlinux1
drivers/built-in.o(.text+0x29dc3): In function `acpi_processor_idle':
: undefined reference to `tsc_c3_compensate'
make: *** [.tmp_vmlinux1] Error 1
lightning linux-2.6.13.2 #

   While I wait for a response on this I think I'll give ck-sources a
try and see what happens with that. Today has been a bear as for
xruns. The machine is quiet for a long time, then I get a burst of
them. It does seem to be mostly disk related. DMA on the hard drive is
enabled at least looking at the hdparm -tT results. I'm a bit
concerned that the NIC driver is listed as experiemental. I may put in
a known good Intel card just to eliminate that as an issue. Problem
with this machine is it's lack of PCI slots being 50% PCI / 50% PCI
Express.

   Thanks in advance for any ideas abot how to fix the above problem.
Most likely some drive I shouldn't be building, etc..

Cheers,
Mark

On 9/16/05, Lee Revell <[hidden email]> wrote:

> On Fri, 2005-09-16 at 16:00 -0700, Mark Knecht wrote:
> > Probably I shouldn't bother with the Gentoo kernel unless we can
> > figure out these FAILED messages. If I shift to the kernel.org kernel
> > Ihave no idea if that has xruns so I'd have to test it first for a few
> > days.
>
> Try it anyway, it might work.
>
> Lee
>
>


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: suddenly seeking xruns

LGTrader
In reply to this post by Phil Frost
On 9/17/05, Phil Frost <[hidden email]> wrote:

> On Fri, Sep 16, 2005 at 04:00:32PM -0700, Mark Knecht wrote:
> >
> > OK. Very happy to help. I'm hoping I can get back to a place where a
> > straight Gentoo kernel works well enough so I don't have to patch. My
> > ATI laptop and my Via desktop have both been great. This is my first
> > AMD64 and my first NVidia chipset.
> >
> > I found that doing hdparm -tT on either the internal EIDE or the 1394
> > drive would cause maybe one or two xruns over the length of the test,
> > which is a short time. Seems like that must be part of the problem.
> >
> > ...
>
> I have an nvidia chipset and amd64 as well. I have an sata hd, but
> initially dma was not enabled for the ata cdrom. hdparm wouldn't let me
> unable it until i did some combination of switching from linux 2.6.10 to
> 2.6.13 and put the nvidia chipset module to load first in /etc/modules;
> hdparm would then allow me to enable dma but it wasn't on by default.
> Perhaps you are having similar problems?
>
> After all my tweaking, running 2.6.13 with realtime-preempt patches, I
> was able to get latency down to about 8 ms but I still get occasional
> streams of xruns, especially when starting programs. My soundcard is an
> audigy 2 zs; the same card got about 2 ms in my old non-64 amd box.
>

Hi Phil,
   It's an interesting idea. From hdparm it appears DMA is enabled,
but I don't like the error message. Maybe there is a problem.

lightning linux-2.6.13.2 # hdparm /dev/cdrom

/dev/cdrom:
 IO_support   =  1 (32-bit)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    = 256 (on)
 HDIO_GETGEO failed: Invalid argument
lightning linux-2.6.13.2 # hdparm /dev/cdrom1

/dev/cdrom1:
 IO_support   =  1 (32-bit)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    = 256 (on)
 HDIO_GETGEO failed: Invalid argument
lightning linux-2.6.13.2 #

That said I do seem to have DMA for the SATA hard drive, but again,
error messages also:

lightning linux-2.6.13.2 # hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   1928 MB in  2.00 seconds = 962.70 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate
ioctl for device
 Timing buffered disk reads:  198 MB in  3.02 seconds =  65.46 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate
ioctl for device
lightning linux-2.6.13.2 #

Thanks,
Mark


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: suddenly seeking xruns

LGTrader
In reply to this post by Lee Revell
On 9/16/05, Lee Revell <[hidden email]> wrote:
> >
>
> If you have the time and the inclination, it would be VERY helpful for
> the kernel developers if, anytime you discover some random thing that
> causes xruns, you could get /proc/latency_trace output or report the
> exact workaround you used.  They are serious about low latency these
> days and consider these to be bugs.

Lee,
   Hi. I've moved a bit forward here in terms of being able to
reliably create the xruns. Through a series of experiments on this
machine and interacting with this machine over the network I've become
pretty convinced the following is true:

a) It is not the 1394 drives, my EIEE DVD or EIDE CDRW

b) It is not networking

c) It is, apparently, my SATA drive

Now I'd like to do the debugging you spoke about.

>
> If you start getting the xruns again, see if unmounting/removing the
> 1394 disk helps at all.  I know that USB storage is or was bad for low
> latency as it disables interrupts for long periods, possibly firewire
> has a similar problem.
>
> Also, make sure to compile the RT kernel with the same preemption mode
> (CONFIG_PREEMPT and not PREEMPT_RT) you got the xruns with.  When you
> boot the RT kernel, do:

Unfortunately I am still unable to build the kernel with Ingo's
patches so my first question is "Can I do the latency tracing for a
kernel such as 2.6.14-rc2-mm21?".

>
> echo 0 > /proc/sys/kernel/preempt_max_latency

For this kernel I do not have the preempt_max_latency entry to set.

lightning linux # echo 0 > /proc/sys/kernel/preempt_max_latency
-bash: /proc/sys/kernel/preempt_max_latency: No such file or directory
lightning linux #
>
> to reset the counter.  Then try to reproduce the xruns.

I'm extrememly interested in doing this if I can get the right kernel
in place. Question is what's the right kernel?

Thanks,
Mark


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel