Re: [LAU] difference between realtime-kernel and low-latency-kernel?

From: Fernando Lopez-Lezcano <nando@email-addr-hidden>
Date: Tue Oct 16 2007 - 19:51:06 EEST

On Tue, 2007-10-16 at 12:34 +1000, porl sheean wrote:
> i think a few people have missed what i mean. after re-reading my post
> i can see it wasn't all that clear. i am still using ubuntustudio, but
> i downloaded the 64studio *kernel* (not the whole distribution, which
> i tried but it wasn't quite what i wanted) to replace ubuntu's.

Arghh, sorry about that, I thought you were running Ubuntu's kernel. So,
everybody else, ignore my comments! :-) (maybe that was explained
somewhere else in the thread and I missed that, sorry again).

> after doing that, everything runs perfectly. i assumed that the ubuntu
> kernel didn't have the rt patches set right, but after downloading a
> vanilla kernel and patching it myself i noticed that my custom kernel
> had the same problems as ubuntu's. whilst i am happy to use the
> 64studio kernel, i am very curious as to what they have done to it to
> make it work where both the ubuntu-rt and my own custom kernel both
> have the same symptoms (*very* unstable audio at lower than 40ms
> latency, and even then ardour often refuses to start plaback - jack
> drops it off as soon as i press play sometimes on larger projects).

That is strange (and interesting).

> i did a diff of the config files from all kernels and couldn't find
> any notable difference that would explain it (to my limited knowledge
> anyway),

Would you mind sending me (or posting) the configuration options for
both kernels? (or rather, three, the one for Ubuntu Studio, 64studio and
your hand rolled kernel?)

> so i assume it is a patch that 64studio has applied in addition to the
> standard rt patch that is making the difference. are there any other
> audio performance enhancing patches for the kernel?

Not that I know of, the only one I'm applying that is related to low
lantency is Ingo's. And I imagine that 64studio uses something like the
rtirq script to tune irq priorities, and that it would treat both
kernels the same.

Puzzling.

-- Fernando

> On 16/10/2007, Fernando Lopez-Lezcano <nando@email-addr-hidden>
> wrote:
> On Sun, 2007-10-14 at 12:48 +1000, porl sheean wrote:
> > i have actually had no end of trouble with ubuntustudio's
> (and now
> > ubuntu's) rt kernel. on an amd 6000+ system with 1gig ram
> and a
> > rme9652 soundcard i can't get reliable performance under 40
> or so ms.
> > i even tried a vanilla kernel with the rt patches and had
> the same
> > trouble. the 64studio kernel worked fine, however. i'm
> currently
> > running at 5ms with it and have had no problems. this is
> even with
> > compiz fusion running and spinning the cube whilst playing
> back audio
> > from an 18 channel ardour project. what patches would cause
> such a
> > difference in performance? it isn't any options selected in
> 'make
> > menuconfig' - i loaded the 64studio's ones in and used them.
> still no
> > luck. i can only assume they have added more patches to do
> with
> > realtime performance than just the -rt patchset.
>
> >From what I gather ubuntustudio does not have an rt patched
> kernel (ie:
> patched with Ingo Molnar's realtime preemption patch). See
> observations
> below:
>
> > On 05/10/2007, thomas fisher <studio1@email-addr-hidden> wrote:
> > I can supply no quantifications for the 32 bit
> 2.6.20-16-realtime
> > kernel in ubuntustudio other than no xruns have been
> observed.
>
> So, Ubuntu Studio has a kernel named realtime and they have
> observed no
> xruns (which is not your case, and not the case of other
> posters).
> Obviously it depends on how they test (hardware used, size of
> buffers,
> load on the machine under test, etc, etc) and there's no info
> on that
> post about that.
>
> > With the low latency kernel, xruns were observed.
>
> This implies they don't have the low latency patches applied
> and that,
> in their experience, the low latency patch was worse than the
> mainline
> kernel.
>
> If you have access to that kernel and you can check its build
> configuration you could grep for "PREEMPT" there and post the
> results.
> That will definitely tell us which options were used for
> building it (I
> suspect you will find just "PREEMPT_VOLUNTARY" there).
>
> In my experience, a mainline kernel will lead to xruns at low
> latencies
> (there's always an exception, of course).
>
> > Jack is the only app that has a -20 priority assigned.
>
> This implies they are not using SCHED_FIFO for running Jack.
> Apparently
> they are boosting the normal scheduler ring priority of Jack
> to -20. I
> have not experimented with this so I can't comment, except to
> say that
> everyone else (that I know of) is using SCHED_FIFO for running
> Jack -
> SCHED_FIFO is a higher priority scheduling method that can't
> be
> preempted by regular linux tasks, and while it is more risky
> as a badly
> designed application can hang the machine, the tradeoff is of
> course
> much better realtime performance.
>
> > The general workstation has been running without fault. The
> general
> > Debian / Ubuntu philosophy tends towards system stability.
>
> The realtime preemption patch is certainly less stable than
> the mainline
> kernel. But if you hardware runs it fine then it is more
> effective than
> mainline for achieving low latencies.
>
> -- Fernando
>
>
> > Tom
> > On Wednesday 03 October 2007 14:54:32 Fernando
> Lopez-Lezcano
> > wrote:
> > > On Wed, 2007-10-03 at 18:39 +0200, Frank Barknecht
> wrote:
> > > > Hallo,
> > > >
> > > > Matthias Schönborn hat gesagt: // Matthias
> Schönborn
> > wrote:
> > > > > I've just read that there's a difference
> between a
> > realtime-kernel and
> > > > > the low-latency-kernel provided by
> ubuntustudio. The
> > text in the german
> > > > > wiki on ubuntuusers.de said, that a
> realtime-kernel is
> > slightly better
> > > > > than the lowlatencykernel
> > ( http://wiki.ubuntuusers.de/Echtzeitkernel) -
> > > > > then why isn't it used in ubuntustudio? Or do
> I just mix
> > something up?
> > > >
> > > > I think, this wiki and maybe Ubuntustudio as
> well are
> > using a very
> > > > confusing terminology.
> > > >
> > > > Generally we have two kinds of kernels: The
> "vanilla"
> > kernel as
> > > > downloadable on kernel.org and the same kernel,
> but
> > patched with Ingo
> > > > Molnars RT-patches. The vanilla kernel, if
> configured
> > properly with
> > > > CONFIG_PREEMPT etc., already gives very good
> performance
> > in the low
> > > > latency department, enough for many users, even
> audio
> > users. I run one
> > > > of these.
> > > >
> > > > If you want more, then you can install a
> RT-patched
> > kernel, as is
> > > > provided in the linux-rt or linux-realtime
> packages. I
> > would call the
> > > > Ingo-Molnar-patched kernels Realtime-Kernels or
> > Low-Latency-Kernels.
> > >
> > > To further clarify (or confuse?) the issue, how
> "low
> > latency" the kernel
> > > is also depends on how you configure the kernel
> build
> > options before or
> > > after patching the kernel with Ingo's patch. For
> Ingo's
> > patch
> > > CONFIG_PREEMPT_RT is the best option in terms of
> latency but
> > there are
> > > others (CONFIG_PREEMPT_DESKTOP) that have a more
> > conservative approach
> > > but have (relatively speaking) higher latencies.
> So from
> > worst to best
> > > it would be something like:
> > >
> > > vanilla linuz + CONFIG_PREEMPT_NONE
> > > vanilla + CONFIG_PREEMPT_VOLUNTARY (used by the
> stock
> > Fedora kernel)
> > > vanilla + Ingo + CONFIG_PREEMPT_DESKTOP
> > > vanilla + Ingo + CONFIG_PREEMPT_RT (the one I
> use for
> > Planet CCRMA)
> > >
> > > (there's more granularity and options in the
> CONFIG_PREEMPT*
> > world but
> > > those are the ones that have the biggest impact as
> far as I
> > can
> > > remember)
> > >
> > > -- Fernando
> > >
> > >
> > > _______________________________________________
> > > Linux-audio-user mailing list
> > > Linux-audio-user@email-addr-hidden
> > >
> >
> http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
> >
> >
> > _______________________________________________
> > Linux-audio-user mailing list
> > Linux-audio-user@email-addr-hidden
> >
> http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
> >
> > _______________________________________________
> > Linux-audio-user mailing list
> > Linux-audio-user@email-addr-hidden
> >
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
>
>
>
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user@email-addr-hidden
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
Received on Tue Oct 16 20:15:02 2007

This archive was generated by hypermail 2.1.8 : Tue Oct 16 2007 - 20:15:02 EEST