16 Oct
2007
16 Oct
'07
12:35 a.m.
---------- Forwarded message ----------
From: porl sheean <porl42(a)gmail.com>
Date: 16 Oct 2007 12:33
Subject: Re: [LAU] difference between realtime-kernel and
low-latency-kernel?
To: Fernando Lopez-Lezcano <nando(a)ccrma.stanford.edu>
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. 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). 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),
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?
thanks porl
On 16/10/2007, Fernando Lopez-Lezcano <nando(a)ccrma.stanford.edu> 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(a)commspeed.net> 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:
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
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(a)lists.linuxaudio.org
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
16 Oct
16 Oct
5:02 a.m.
Porl, I can understand where you're coming from on this.
I have a machine here that I play around with mostly to understand the debian system on.
Though most of the time I use fedora-ccrma on my my main machine, I've taken some care
to get sound working well on this 2nd(debian based) machine.
The machine has both 64studio and ubuntu(not studio, but the ubuntu low-latency kernel).
For me, 64studio is a fantastic audio distribution with very low latency capabilities.
But no matter how hard I've tried over the past few years, ubuntu seems like a lost
cause. I've also tried the kernel from 64studio on ubuntu and got much better results
running audio apps in ubuntu, but I don't want to mess up ubuntu too much by dragging
a whole lot of extras over just to make up for ubuntu's audio problems.
I haven't been following the ubuntu/ubuntu-studio thing too well; but I thought that
the problems are that the studio folks know what they're doing(for audio work), while
the folks who run the distro have little interest in specifically fine tuning the system
for audio work. Now, it's not that just ubuntu has this problem; if you want to look
it up you can find Ingo's rants on how the redhat/fedora people insist on keeping the
disk system's settings so conservative.
It seems until we see all of the low latency stuff into the mainstream kernels, and the
redhat and ubuntus give us better tuning options(especially on the the desktop); that
audio distros such as 64studio or fedora(with Fernando/Ingo's patched kernels, tweaked
pam, and other suggestions) are our best bet. I'm not trying to say that those two
are the only ones(there is a gentoo system here that does as well as 64studio and
fedora/ccrmart (but then, if you run gentoo it's understood that you tune your system
the way you want it(so ok, gentoo has it's problems also(like not updating the pam
system to use rtlimits for close to a year and setting it far behind other distros)))).
And no, I haven't tried the suse audio stuff(mostly because I dislike the way yast
won't let me change things on my own or the way I want to).
I could go on with this rant, but some troll from some mainstream computer magazine might
think it's contents(taken out of perspective of course) could be a great anti-linux
story. The truth is that us audio folks just want the best, and a properly tuned linux
system is fantastic for low latency audio work.
The best I can say is use a custom_low_latency_kernel, tune up the pam system, use noatime
on your disks, tell the window manager not to poll the i/o system, and use things like
Rui's rtirq if needed.
Tracey.
2:51 p.m.
New subject: difference between realtime-kernel and low-latency-kernel?
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(a)ccrma.stanford.edu>
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(a)commspeed.net> 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
I
just mix
> > than the lowlatencykernel
( http://wiki.ubuntuusers.de/Echtzeitkernel) -
> > > then why isn't it used in ubuntustudio? Or do 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
"low
> Ingo-Molnar-patched kernels Realtime-Kernels
or
Low-Latency-Kernels.
>
> To further clarify (or confuse?) the issue, how 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
So from
others (CONFIG_PREEMPT_DESKTOP) that have a more
conservative approach
> but have (relatively speaking) higher latencies. 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
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
remember)
-- Fernando
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
18 Oct
18 Oct
10:59 a.m.
sorry, i buggered the send options, so i'll send it again:
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?)
i'll give it a go, but i accidently overwrote one of
them (the 64 studio one
i think) when i was trying to compare them :( i'm actually trying the
2.6.2364studio kernel test version, because i just found out there was
a
regression in the 2.6.22 one with incorrectly set up firewire (which i'm
trying to get going now.... ). grr... plot thickens :)
from memory though, most of the differences were merely driver modules and
filesystem types supported more than anything.
porl
6339
days inactive
6342
days old
linux-audio-user@lists.linuxaudio.org
3 comments
3 participants
participants (3)
-
Fernando Lopez-Lezcano -
porl sheean -
Tracey Hytry