"yum install ...." based instruction on building a RT kernel.

"yum install ...." based instruction on building a RT kernel.

[Gautam Thaker]

https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO

The above page provides the instruction in  a step by step manner, but I 
distinctly recall that Ingo Molnar used to have some place a set of 
instruction that were "yum" based and it seemed like it was just  a couple of 
commands to build a new RT kernel. Are these still available anywhere?


There is the link below, but it appears to be > 3 years old and itself points 
to some broken links.

http://wiki.bestpractical.com/view/RPMInstall

It would be nice to have something like "yum install rt ..." to get the latest 
version of RT kernel build.

Gautam

Re: "yum install ...." based instruction on building a RT kernel.

[jordan]

Hi Gautam,

> The above page provides the instruction in  a step by step manner, but I
> distinctly recall that Ingo Molnar used to have some place a set of
> instruction that were "yum" based and it seemed like it was just  a couple
> of commands to build a new RT kernel. Are these still available anywhere?

Correct me if im wrong, but wouldn't you be required to either A: be
using a repository that has packaged rt-kernels,
or B: have the RPMs for the rt-kernel locally, on your machine....?
(to use the yum or rpm methods).

> There is the link below, but it appears to be > 3 years old and itself
> points to some broken links.
>
> http://wiki.bestpractical.com/view/RPMInstall
>
> It would be nice to have something like "yum install rt ..." to get the
> latest version of RT kernel build.

Ubuntu does something like that. But, it wont give you the latest,
just what is available. IF you want the latest get the sources.....I
don't use Ubuntu, as i use Fedora. But when i did try ubuntu with a
"stock" rt-kernel from the repo, it wasn't all that great.

*  don't you think it is fairly simple task to just get kernel
sources, use the corresponding rt-patch for the given kernel, and then
just compile it?   If you have never done this before, it is actually
quite simple once you go through it, once or twice.  It also has some
advantages, i have always had better quality kernels when i tune and
compile them myself....

Then you could also strip away all of the modules, that your machine
wont need, that would be built into a more generic kernel, available
in a repo.

You could also optimize your kernel further, disable features that you
dont need. maybe compile the kernel specifically for your cpu...

Patching the kernel is not hard, nor is compiling it, nor optimizing it.

I know for myself, even if i could just install an rt-kernel using
yum, i probably wouldn't.
It wouldn't be as good as doing it myself.

just my opinions

cheerz

jordan
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: "yum install ...." based instruction on building a RT kernel.

[John Kacur]

On Fri, Sep 17, 2010 at 8:08 AM, jordan <triplesquarednine@gmail.com> wrote:
> Hi Gautam,
>
>> The above page provides the instruction in  a step by step manner, but I
>> distinctly recall that Ingo Molnar used to have some place a set of
>> instruction that were "yum" based and it seemed like it was just  a couple
>> of commands to build a new RT kernel. Are these still available anywhere?
>
> Correct me if im wrong, but wouldn't you be required to either A: be
> using a repository that has packaged rt-kernels,
> or B: have the RPMs for the rt-kernel locally, on your machine....?
> (to use the yum or rpm methods).
>
>> There is the link below, but it appears to be > 3 years old and itself
>> points to some broken links.
>>
>> http://wiki.bestpractical.com/view/RPMInstall
>>
>> It would be nice to have something like "yum install rt ..." to get the
>> latest version of RT kernel build.
>
> Ubuntu does something like that. But, it wont give you the latest,
> just what is available. IF you want the latest get the sources.....I
> don't use Ubuntu, as i use Fedora. But when i did try ubuntu with a
> "stock" rt-kernel from the repo, it wasn't all that great.
>
> *  don't you think it is fairly simple task to just get kernel
> sources, use the corresponding rt-patch for the given kernel, and then
> just compile it?   If you have never done this before, it is actually
> quite simple once you go through it, once or twice.  It also has some
> advantages, i have always had better quality kernels when i tune and
> compile them myself....
>
> Then you could also strip away all of the modules, that your machine
> wont need, that would be built into a more generic kernel, available
> in a repo.
>
> You could also optimize your kernel further, disable features that you
> dont need. maybe compile the kernel specifically for your cpu...
>
> Patching the kernel is not hard, nor is compiling it, nor optimizing it.

You think that optimizing it is easy?

>
> I know for myself, even if i could just install an rt-kernel using
> yum, i probably wouldn't.
> It wouldn't be as good as doing it myself.
>
> just my opinions
>

There is something called Planet CCRMA, which is a set of
repositories for audio packages that run on RedHat, Fedora and CentOS.
They also package the real-time kernel in rpm form. However, it is rather
out of date. If you can compile your own kernel that would be the
preferred option, but if you don't know how and still want to try
out the real-time kernel then you can fetch it from there.

Here is the link
http://ccrma.stanford.edu/planetccrma/software/

Have fun.
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: "yum install ...." based instruction on building a RT kernel.

[Daniel James]

Hi John,

> There is something called Planet CCRMA, which is a set of
> repositories for audio packages that run on RedHat, Fedora and CentOS.
> They also package the real-time kernel in rpm form.

Ready-packaged RT kernels make sense for JACK users with generic PCs,
who may not be all that interested in optimisation (at first). They just
want to be able to install a program like Ardour and have it run
glitch-free.

Being a release or two behind the bleeding edge is no bad thing for that
type of user either - if (for instance) 2.6.31-rt works fine in a
production audio system, there's no big hurry to change it and
potentially break stuff. For that sort of user, high availability is
much more important than squeezing every last drop of performance out of
the hardware.

In audio recording, we're potentially capturing once-in-a-lifetime or
one-time-ever events, particularly since the industry focus has shifted
from the studio to the live stage - whether TV, stadium or festival,
that's where the artists are making their living these days. Even
festivals run to tight schedules, with only 15 minutes allowed to switch
between acts, including moving all the gear and repatching it. You can't
ask the band to go and get a beer while you recompile your kernel :-)

Cheers!

Daniel

Re: "yum install ...." based instruction on building a RT kernel.

[Bernardo Barros]

Maybe this helps:
http://fedoraproject.org/wiki/Docs/CustomKernel

2010/9/17 Daniel James <daniel@64studio.com>:
> Hi John,
>
>> There is something called Planet CCRMA, which is a set of
>> repositories for audio packages that run on RedHat, Fedora and CentOS.
>> They also package the real-time kernel in rpm form.
>
> Ready-packaged RT kernels make sense for JACK users with generic PCs,
> who may not be all that interested in optimisation (at first). They just
> want to be able to install a program like Ardour and have it run
> glitch-free.
>
> Being a release or two behind the bleeding edge is no bad thing for that
> type of user either - if (for instance) 2.6.31-rt works fine in a
> production audio system, there's no big hurry to change it and
> potentially break stuff. For that sort of user, high availability is
> much more important than squeezing every last drop of performance out of
> the hardware.
>
> In audio recording, we're potentially capturing once-in-a-lifetime or
> one-time-ever events, particularly since the industry focus has shifted
> from the studio to the live stage - whether TV, stadium or festival,
> that's where the artists are making their living these days. Even
> festivals run to tight schedules, with only 15 minutes allowed to switch
> between acts, including moving all the gear and repatching it. You can't
> ask the band to go and get a beer while you recompile your kernel :-)
>
> Cheers!
>
> Daniel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: "yum install ...." based instruction on building a RT kernel.

[John Kacur]

On Fri, Sep 17, 2010 at 2:38 PM, Daniel James <daniel@64studio.com> wrote:
> Hi John,
>
>> There is something called Planet CCRMA, which is a set of
>> repositories for audio packages that run on RedHat, Fedora and CentOS.
>> They also package the real-time kernel in rpm form.
>
> Ready-packaged RT kernels make sense for JACK users with generic PCs,
> who may not be all that interested in optimisation (at first). They just
> want to be able to install a program like Ardour and have it run
> glitch-free.
>
> Being a release or two behind the bleeding edge is no bad thing for that
> type of user either - if (for instance) 2.6.31-rt works fine in a
> production audio system, there's no big hurry to change it and
> potentially break stuff. For that sort of user, high availability is
> much more important than squeezing every last drop of performance out of
> the hardware.
>
> In audio recording, we're potentially capturing once-in-a-lifetime or
> one-time-ever events, particularly since the industry focus has shifted
> from the studio to the live stage - whether TV, stadium or festival,
> that's where the artists are making their living these days. Even
> festivals run to tight schedules, with only 15 minutes allowed to switch
> between acts, including moving all the gear and repatching it. You can't
> ask the band to go and get a beer while you recompile your kernel :-)

Well, you've certainly slayed a straw man there. Just because I said it would
be good for people to compile their own kernels doesn't mean I meant
for them to do it on stage! Btw, I quite enjoy studio64, feel free to
update our rtwiki
with information about it.

Thanks.

Re: EXTERNAL: Re: "yum install ...." based instruction on building a RT kernel.

[Gautam Thaker]

Bernardo Barros wrote:
> Maybe this helps:
> http://fedoraproject.org/wiki/Docs/CustomKernel
> 

Thanks to everyone for their replies. I have indeed build RT kernel many many times before, and it is not very 
difficult, but I tend to not really spend a lot of time removing modules I don't need etc as I don't need to worry about 
disk footprint etc.

I was hoping for something even quicker, but yes the basic steps are not that hard.

As for the link above, I must say it gives steps that seem 5-10x more complicated (more keyboard stokes, etc) than even 
the direct, manual method, so this semes like to win.... Can't believe this is the official procedure from fedoraproject.

Gautam

Re: "yum install ...." based instruction on building a RT kernel.

[jordan]

Hey John,

> You think that optimizing it is easy?

Yes, i do. :)

1. Patching the kernel is simple (as long as you are using the right
patch with the right version). Most of the time it is as simple as
putting the patch in the kernel's directory and running:

patch -p1 <  "whatever the patch is called"

Then it will show you if it patched correctly, if it didn't hit a
linux forum and ask for help.  It isn't rocket science...

2. To strip away all modules that you don't require, you only need to
run a simple command from a terminal before you compile:

"make localmodconfig".

Then you can use "make menuconfig or mkae xconfig", and look through
the configuration, then disable features that you don't need or want.
Alot of the time it is common sense, as some things will be obvious to
most people, that they are features your hardware/setup doesn't
require. other times, google will be your bestfriend.

3. After that, you can hit the gentoo documentation and/or the GCC
documentation, and read about CFLAGS...once, you figure out what you
may like to use, and what isn't dangerous (too harsh of optimizations
can break things).
Then, you can run the necessary commands when you go to compile.

my example (these are for my machine, and i use strict optimizations,
so don't assume you should use them!)

'make CFLAGS="-O3 -march=native -pipe -fomit-frame-pointer -DPIC -fPIC
-s" LDFLAGS="-z combreloc" rpm'

(in my case this will make my optimized kernel into RPMs to use with Fedora)

4. Let it compile, if that goes okay, install it. then, depending on
your distro/method used by the distro, you may have to use "dracut" or
some other tool that make your initrd and you might manually have to
edit grub.
After this is all completed reboot!

if there are any problems booting into your new kernel, google the
error message and fix the problem.
if you need help hit a forum.

I don't think that is difficult. I taught myself how to do this, and
im not a genius! (it's like 5 terminal commands, some reading and
following instructions, easily found on the interweb)

jordan

Re: "yum install ...." based instruction on building a RT kernel.

[jordan]

On Fri, Sep 17, 2010 at 8:38 AM, Daniel James <daniel@64studio.com> wrote:
> Hi John,
>
>> There is something called Planet CCRMA, which is a set of
>> repositories for audio packages that run on RedHat, Fedora and CentOS.
>> They also package the real-time kernel in rpm form.
>
> Ready-packaged RT kernels make sense for JACK users with generic PCs,
> who may not be all that interested in optimisation (at first). They just
> want to be able to install a program like Ardour and have it run
> glitch-free.

I generally agree with you Daniel, this rings true. But myself, i have
been able to improve latency and performance dramatically, by not
using pre-packaged rt-kernels.  Once users get more advanced in their
understanding, there are a number of things you can tune in the
kernel. (i know you already know this)...

> Being a release or two behind the bleeding edge is no bad thing for that
> type of user either - if (for instance) 2.6.31-rt works fine in a
> production audio system, there's no big hurry to change it and
> potentially break stuff. For that sort of user, high availability is
> much more important than squeezing every last drop of performance out of
> the hardware.

true enough. 2.6.32 and 2.6.33 are much nicer though...

> In audio recording, we're potentially capturing once-in-a-lifetime or
> one-time-ever events, particularly since the industry focus has shifted
> from the studio to the live stage - whether TV, stadium or festival,
> that's where the artists are making their living these days. Even
> festivals run to tight schedules, with only 15 minutes allowed to switch
> between acts, including moving all the gear and repatching it. You can't
> ask the band to go and get a beer while you recompile your kernel :-)

Ideally, no one would ever be compiling the kernel at a show, lol. I
know I never would! lol....that's hilarious.
You do that stuff on your own time!  Artists have always made their
money live, and through merchandise. Record sales go into the Label's
pockets for the most part.

jordan

Re: EXTERNAL: Re: "yum install ...." based instruction on building a RT kernel.

[jordan]

Hi Gautum,

> As for the link above, I must say it gives steps that seem 5-10x more
> complicated (more keyboard stokes, etc) than even the direct, manual method,
> so this semes like to win.... Can't believe this is the official procedure
> from fedoraproject.

I took one look at that documentation, and decided NOT to use it. It's
much easier to use the more manual/standard way to compile the linux
kernel. (as you say) The offical Fedora way is absolutely brutal!!
(and there is no real advantage!). It seems really redundant to me, as
i compile the linux kernel frequently, i stay more towards the
bleeding edge. (more so than Fedora is anyway).

jordan

Re: "yum install ...." based instruction on building a RT kernel.

[jordan]

Hi John,

I forgot number 5....

Once, you have a working rt-kernel, read up the linux schedulers (ie:
CFS and CFQ). Then, tune those as well.
As you would know working for redhat, these can be tuned after the
kernel is compiled. There are methods to do this littered all over the
internet.  You can use all sorts of tools (cyclictest/signaltest/etc)
to accurately see what effect your changes are making...then you test
with your applications for "real-world" tests/performance.

So, there is a learning curve. I would be lying, if i didn't
acknowledge this, But once you have done it a few times, it is
knowledge that you have, and won't have to re-learn.  Then, it becomes
very simple to do. (this applies to everything i wrote about)

jordan

Re: "yum install ...." based instruction on building a RT kernel.

[Clark Williams]

[-- Attachment #1: Type: text/plain, Size: 2034 bytes --]

On Sat, 18 Sep 2010 15:24:18 -0400
jordan <triplesquarednine@gmail.com> wrote:

> > Being a release or two behind the bleeding edge is no bad thing for that
> > type of user either - if (for instance) 2.6.31-rt works fine in a
> > production audio system, there's no big hurry to change it and
> > potentially break stuff. For that sort of user, high availability is
> > much more important than squeezing every last drop of performance out of
> > the hardware.
> 
> true enough. 2.6.32 and 2.6.33 are much nicer though...

I'll second this sentiment. We were going to to release a new realtime
kernel with the .31 series, but testing showed that it had some
significant regressions in terms of event response time and in overall
throughput, so we held off. The .33 series is much better in those
regards and that's what we'll be going out with in our next release. 

> 
> > In audio recording, we're potentially capturing once-in-a-lifetime or
> > one-time-ever events, particularly since the industry focus has shifted
> > from the studio to the live stage - whether TV, stadium or festival,
> > that's where the artists are making their living these days. Even
> > festivals run to tight schedules, with only 15 minutes allowed to switch
> > between acts, including moving all the gear and repatching it. You can't
> > ask the band to go and get a beer while you recompile your kernel :-)
> 
> Ideally, no one would ever be compiling the kernel at a show, lol. I
> know I never would! lol....that's hilarious.
> You do that stuff on your own time!  Artists have always made their
> money live, and through merchandise. Record sales go into the Label's
> pockets for the most part.
> 

Heh. I haven't actually compiled a kernel on stage, but a friend of
mine reworked a play's audio track 20 minutes before curtain when the
Windows box ate it's disk; he booted up his Linux laptop and ran the
sound sequencer program in a QEMU instance. I think I'd rather rebuild
a kernel under the gun :).


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: "yum install ...." based instruction on building a RT kernel.

[jordan]

Hi Clark,

> I'll second this sentiment. We were going to to release a new realtime
> kernel with the .31 series, but testing showed that it had some
> significant regressions in terms of event response time and in overall
> throughput, so we held off. The .33 series is much better in those
> regards and that's what we'll be going out with in our next release.

Ya, i liked .33 - it would be a great choice. There were a lot of
perfromance gains in that kernel... Recently, i have changed laptops
(my good one died). Unfortunately, this laptop i am using now has
buggy hardware. But i am stuck with it, until my next machine is
built...

I actually, am having to use BFS and BFQ and avoid rtirq, etc.  I've
had to take a totally different method to get smooth, reliable audio
performance (at low latency). But all my work has paid, and my system
is quite robust. im using 2.6.34 optimized like crazy. I've been
impressed though, as the system never has problems, even with it's
inherent issues, and under significant CPU-load. Even, though my
method seems to work perfect, and is actually simple to use. I am
looking forward to when i can finish building my new rackmount, and
get back to the standard way of doing things.

> Heh. I haven't actually compiled a kernel on stage, but a friend of
> mine reworked a play's audio track 20 minutes before curtain when the
> Windows box ate it's disk; he booted up his Linux laptop and ran the
> sound sequencer program in a QEMU instance. I think I'd rather rebuild
> a kernel under the gun :).

That's why i use linux live, Windows is scary for that purpose. * I
would much rather compile the kernel under pressure. it only takes
10minutes! *
Using \x10Linux, I am still able to use lots of windows VSTi (NI
Komplete) coupled with linux apps. It works perfectly.
Even on a junker dell inspiron 6400 (e1505), coreduo 1.6ghz, 1gig ram.
 I am able to run somewhere around 8-12 Vst instruments (big ones
too), sooperlooper, FX chains, live audio-inputs (mic and guitar),
all @ 128 frames in jack, and i never have issues. When i did try to
use Windows live, i ran into problems. High latency, crashing, etc.
Even with my Macbook that died, i'd run into the similar issues. (when
using Mac OS anyway).

Linux seems to work nicely, even on junk "craptops"   It'll be funny
to see how the new rack will perform!

jordan

Re: "yum install ...." based instruction on building a RT kernel.

[Bernardo Barros]

Hey jordan,

Could you share your optimizations with us? I'm also runnins 2.6.34
here (2.6.34.6-54.fc13.x86_64),
I have problems with my rt-kernel, it freezes my system (thinkpad
w510). Maybe something with video card or whatever, but I don't have
the time to really investigate what is happening, so I must get the
best from the generic kernel for now :-)


2010/9/19 jordan <triplesquarednine@gmail.com>:
> Hi Clark,
>
>> I'll second this sentiment. We were going to to release a new realtime
>> kernel with the .31 series, but testing showed that it had some
>> significant regressions in terms of event response time and in overall
>> throughput, so we held off. The .33 series is much better in those
>> regards and that's what we'll be going out with in our next release.
>
> Ya, i liked .33 - it would be a great choice. There were a lot of
> perfromance gains in that kernel... Recently, i have changed laptops
> (my good one died). Unfortunately, this laptop i am using now has
> buggy hardware. But i am stuck with it, until my next machine is
> built...
>
> I actually, am having to use BFS and BFQ and avoid rtirq, etc.  I've
> had to take a totally different method to get smooth, reliable audio
> performance (at low latency). But all my work has paid, and my system
> is quite robust. im using 2.6.34 optimized like crazy. I've been
> impressed though, as the system never has problems, even with it's
> inherent issues, and under significant CPU-load. Even, though my
> method seems to work perfect, and is actually simple to use. I am
> looking forward to when i can finish building my new rackmount, and
> get back to the standard way of doing things.
>
>> Heh. I haven't actually compiled a kernel on stage, but a friend of
>> mine reworked a play's audio track 20 minutes before curtain when the
>> Windows box ate it's disk; he booted up his Linux laptop and ran the
>> sound sequencer program in a QEMU instance. I think I'd rather rebuild
>> a kernel under the gun :).
>
> That's why i use linux live, Windows is scary for that purpose. * I
> would much rather compile the kernel under pressure. it only takes
> 10minutes! *
> Using  Linux, I am still able to use lots of windows VSTi (NI
> Komplete) coupled with linux apps. It works perfectly.
> Even on a junker dell inspiron 6400 (e1505), coreduo 1.6ghz, 1gig ram.
>  I am able to run somewhere around 8-12 Vst instruments (big ones
> too), sooperlooper, FX chains, live audio-inputs (mic and guitar),
> all @ 128 frames in jack, and i never have issues. When i did try to
> use Windows live, i ran into problems. High latency, crashing, etc.
> Even with my Macbook that died, i'd run into the similar issues. (when
> using Mac OS anyway).
>
> Linux seems to work nicely, even on junk "craptops"   It'll be funny
> to see how the new rack will perform!
>
> jordan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: "yum install ...." based instruction on building a RT kernel.

[jordan]

Hey Bernardo,

> Could you share your optimizations with us? I'm also runnins 2.6.34
> here (2.6.34.6-54.fc13.x86_64),
> I have problems with my rt-kernel, it freezes my system (thinkpad
> w510). Maybe something with video card or whatever, but I don't have
> the time to really investigate what is happening, so I must get the
> best from the generic kernel for now :-)

yes, i can do that.  I am however, heading off to band practice. I
will also need to dig up some resources(web-links) that will help you.
The only things i wont be able to help you that much with, is what
CFLAG optimizations to use with x86_64. Although i do have a 64bit
install on my deksotp. it is my 32bit platform that is highly-tuned,
as 32bit is better for my Wine/VST usage. Most of the settings that i
use will work fine though.
Can i assume that you are fairly tech-savvy, or have a good linux
knowledge base????

First, i will recommend checking out Zen-kernel (www.zen-kernel.org) -
* if you do not want to have to patch the kernel several times over,
this is a great option *
these guys include all the non-upstream stuff, that will be required/useful...

jordan

Re: "yum install ...." based instruction on building a RT kernel.

[jordan]

[-- Attachment #1: Type: text/plain, Size: 6844 bytes --]

Hey bernardo,

i forgot to get back to you, as i have been a bit busy. sorry.

> Hey jordan,
>
> Could you share your optimizations with us? I'm also runnins 2.6.34
> here (2.6.34.6-54.fc13.x86_64),
> I have problems with my rt-kernel, it freezes my system (thinkpad
> w510). Maybe something with video card or whatever, but I don't have
> the time to really investigate what is happening, so I must get the
> best from the generic kernel for now :-)

So as i said before, you should check out Zen-kernel.org.... You will
need to use GIT to get the sources. There are great instructions in
their documentation section, for both installation on a Fedora system
and on how to use GIT properly (if you don't know how).

Once you have gotten the sources, and picked what branch to checkout.
Run "make localmodconfig" from the kernel's directory. This will trim
off most of the fat in the kernel.  After that, type "make
menuconfig", now you will be able to select what other features to use
in your kernel.  I typically disable anything that i don't need.

The most important things to use for low latency are these:

BFS scheduler (CPU)  -   this will provide low latency
BFQ scheduler (IO)  -     this will help tune your io-scheduling

(there are others, like using 1000hz and making sure "preemption" is
checked off. but i believe that these should be setup by default, have
a look around the kernel configuration, most settings will have an
explanation if you select them and then use "help"). you can also type
"?"  and search for a setting which can be very helpful.

both of these schedulers have tunables. you can reduce latency
(sometimes at the cost of through put)
and BFS provides a feature called SCHED_ISO, which can be used with
the utility "schedtools".   SCHED_ISO can be used to raise priorites
of an application, for example when i start Jackd (using qjackctl), i
will start it with:

schedtools -I -e qjackctl

This will give all of jack's threads a higher priority, minus the main
jackd thread which will be using FIFO.
This should give your audio a little more importance than every other
process running.

One important note! :    In Zen-kernel's "menuconfig" under general
setup, there is an option to "automatically use SCHED_ISO for X"  -
make sure that is disabled, otherwise X might screw with Jackd, and
you might get xruns.  Usually, this setting is used to speed up the
desktop experience. Using low latency for audio, you should care more
about making sure your audio is Number 1!!! (and not X).

You will also want to optimize the kernel as best as you can, and try
using CFLAGS. I use some pretty harsh optimizations, that i can't
really recommend, But try things out for yourself. Read up on GCC and
how to use CFLAGS (there is good documentation in the gentoo
handbook), then when you are going to compile specify your flags -
there is also a section in Zen-kernel called "custom CFLAGS" or
something like that.

again some of this you will need to read up on, and experiment with.

once you have your kernel configured it should be as simple as

1. running "make rpm" then,
2. installing those rpm's using "rpm -ivh yourkernel.rpm",
3. then running "dracut /boot/initramfs-yourkernel.img" and then
4. modifying your grub/add your new kernel to it. then reboot.

Once, you do have a running kernel, you will want to adjust BFS and
BFQ's tunables. I will show you some examples.  To make things easy on
myself, i just put these into /etc/rc.local (this way they execute on
startup, and are easily modified, and easy to track changes)::

echo bfq > /sys/block/sda/queue/scheduler

# BFQ

echo 0 > /sys/block/sda/queue/iosched/low_latency       (this one is
really important)

echo 8 > /sys/block/sda/queue/iosched/quantum

echo 140 > /sys/block/sda/queue/iosched/timeout_sync

echo 200 > /sys/block/sda/queue/iosched/timeout_async

echo 8 > /sys/block/sda/queue/iosched/max_budget_async_rq

My BFQ settings may not be optimal for your system, my system is junk,
but after a lot of trial and error
these values seem to work best for me.

# BFS

echo 90 > /proc/sys/kernel/iso_cpu

echo 2 > /proc/sys/kernel/rr_interval

BFS only has 2 useful tunables. again play around a bit, but these
work best for me, by far!

# Other Kernel settings

echo 1500 > /proc/sys/vm/dirty_writeback_centisecs

echo 0 > /proc/sys/vm/laptop_mode

echo 0 >> /sys/module/snd_hda_intel/parameters/power_save

echo 64 >> /proc/sys/dev/hpet/max-user-freq

echo 2048 >> /sys/class/rtc/rtc0/max_user_freq

hdparm -m16 -B255 --yes-i-know-what-i-am-doing /dev/sda

Do NOT just copy these, especially my setting for "hdparm" could harm
your system and cause you problems!
my setting for hdparm are very specific - hence the
"--yes-i-know-what-i-am-doing" flag, lol.

however, the rest are probably okay, or might not apply to your hardware.

I also have other tweaks that i use, in my case i am using Fedora 13,
so many parts of the system have been recompiled, or taken out. I
obviously disable compositing desktop, as well as any and all services
that i do not use, i also ditch any and all software i don't use and
their dependencies. i also modify /etc/fstab using things like the
"noatime" parameter.  I will show you how mine looks (i'll attach a
screenshot).
You will also notice my partition map - everything was divided on
install. seperate /home, /usr , /var, /tmp and of course / (root).
this way i can specify different parameters and most importantly home
and root are seperate!

 The end result is good though:

Dell Inspiron 6400
CoreDuo 1.6ghz
1 gig RAM
ATI x1300
IntelHDA
320gig 5400 rpm HDD

In the case of Jackd, will have 128 frames with a period of 2.   I
could run say Ardour with 10-20 tracks, no xruns. I can run many VST
instruments (using wine) with FX chains, or substantial routings, and
the only xruns i will get are usually on startup of a given plugin.

When i am doing post-production, i simply change the frames to 1024,
then ardour with a boat load or plugins, still wont cause xruns.  In
my case it has worked out really well.  I am currently using:

2.6.35-zen2+

which works better than the planet CCRMA rt-kernel.  it also works
better than the puppy linux rt-kernel and better than ubuntu's
rt-kernel on my hardware. this crappy old dell, actually works quite
nicely for pro-audio and i have squeezed out a lot of extra
performance.  I will have to think about what else i am using in the
kernel that may boost performance, but this should give you a decent
start.

Soon this machine will be retired as i only need 2-3 more components
for my AMD Phenom x4 965 3.40ghz system with 8gig ram DDR3 and a
7200rpm HDD - Which will be plenty fast. (especially once i optimize
it with Open64 compiler).

if you have any questions, just ask, and again sorry for forgetting to
reply, i have been a busy boy!

jordan

[-- Attachment #2: fstab.png --]
[-- Type: image/png, Size: 53907 bytes --]

Re: "yum install ...." based instruction on building a RT kernel.

[John Kacur]

----- "jordan" <triplesquarednine@gmail.com> wrote:

> Hey bernardo,
> 
> i forgot to get back to you, as i have been a bit busy. sorry.
> 
> > Hey jordan,
> >
> > Could you share your optimizations with us? I'm also runnins 2.6.34
> > here (2.6.34.6-54.fc13.x86_64),
> > I have problems with my rt-kernel, it freezes my system (thinkpad
> > w510). Maybe something with video card or whatever, but I don't
> have
> > the time to really investigate what is happening, so I must get the
> > best from the generic kernel for now :-)
> 
> So as i said before, you should check out Zen-kernel.org.... You will
> need to use GIT to get the sources. There are great instructions in
> their documentation section, for both installation on a Fedora system
> and on how to use GIT properly (if you don't know how).
> 
> Once you have gotten the sources, and picked what branch to checkout.
> Run "make localmodconfig" from the kernel's directory. This will trim
> off most of the fat in the kernel.  After that, type "make
> menuconfig", now you will be able to select what other features to
> use
> in your kernel.  I typically disable anything that i don't need.
> 
> The most important things to use for low latency are these:
> 
> BFS scheduler (CPU)  -   this will provide low latency
> BFQ scheduler (IO)  -     this will help tune your io-scheduling
> 
> (there are others, like using 1000hz and making sure "preemption" is
> checked off. but i believe that these should be setup by default,
> have
> a look around the kernel configuration, most settings will have an
> explanation if you select them and then use "help"). you can also
> type
> "?"  and search for a setting which can be very helpful.
> 
> both of these schedulers have tunables. you can reduce latency
> (sometimes at the cost of through put)
> and BFS provides a feature called SCHED_ISO, which can be used with
> the utility "schedtools".   SCHED_ISO can be used to raise priorites
> of an application, for example when i start Jackd (using qjackctl), i
> will start it with:
> 
> schedtools -I -e qjackctl
> 
> This will give all of jack's threads a higher priority, minus the
> main
> jackd thread which will be using FIFO.
> This should give your audio a little more importance than every other
> process running.
> 
> One important note! :    In Zen-kernel's "menuconfig" under general
> setup, there is an option to "automatically use SCHED_ISO for X"  -
> make sure that is disabled, otherwise X might screw with Jackd, and
> you might get xruns.  Usually, this setting is used to speed up the
> desktop experience. Using low latency for audio, you should care more
> about making sure your audio is Number 1!!! (and not X).
> 
> You will also want to optimize the kernel as best as you can, and try
> using CFLAGS. I use some pretty harsh optimizations, that i can't
> really recommend, But try things out for yourself. Read up on GCC and
> how to use CFLAGS (there is good documentation in the gentoo
> handbook), then when you are going to compile specify your flags -
> there is also a section in Zen-kernel called "custom CFLAGS" or
> something like that.
> 
> again some of this you will need to read up on, and experiment with.
> 
> once you have your kernel configured it should be as simple as
> 
> 1. running "make rpm" then,
> 2. installing those rpm's using "rpm -ivh yourkernel.rpm",
> 3. then running "dracut /boot/initramfs-yourkernel.img" and then
> 4. modifying your grub/add your new kernel to it. then reboot.
> 
> Once, you do have a running kernel, you will want to adjust BFS and
> BFQ's tunables. I will show you some examples.  To make things easy
> on
> myself, i just put these into /etc/rc.local (this way they execute on
> startup, and are easily modified, and easy to track changes)::
> 
> echo bfq > /sys/block/sda/queue/scheduler
> 
> # BFQ
> 
> echo 0 > /sys/block/sda/queue/iosched/low_latency       (this one is
> really important)
> 
> echo 8 > /sys/block/sda/queue/iosched/quantum
> 
> echo 140 > /sys/block/sda/queue/iosched/timeout_sync
> 
> echo 200 > /sys/block/sda/queue/iosched/timeout_async
> 
> echo 8 > /sys/block/sda/queue/iosched/max_budget_async_rq
> 
> My BFQ settings may not be optimal for your system, my system is
> junk,
> but after a lot of trial and error
> these values seem to work best for me.
> 
> # BFS
> 
> echo 90 > /proc/sys/kernel/iso_cpu
> 
> echo 2 > /proc/sys/kernel/rr_interval
> 
> BFS only has 2 useful tunables. again play around a bit, but these
> work best for me, by far!
> 
> # Other Kernel settings
> 
> echo 1500 > /proc/sys/vm/dirty_writeback_centisecs
> 
> echo 0 > /proc/sys/vm/laptop_mode
> 
> echo 0 >> /sys/module/snd_hda_intel/parameters/power_save
> 
> echo 64 >> /proc/sys/dev/hpet/max-user-freq
> 
> echo 2048 >> /sys/class/rtc/rtc0/max_user_freq
> 
> hdparm -m16 -B255 --yes-i-know-what-i-am-doing /dev/sda
> 
> Do NOT just copy these, especially my setting for "hdparm" could harm
> your system and cause you problems!
> my setting for hdparm are very specific - hence the
> "--yes-i-know-what-i-am-doing" flag, lol.
> 
> however, the rest are probably okay, or might not apply to your
> hardware.
> 
> I also have other tweaks that i use, in my case i am using Fedora 13,
> so many parts of the system have been recompiled, or taken out. I
> obviously disable compositing desktop, as well as any and all
> services
> that i do not use, i also ditch any and all software i don't use and
> their dependencies. i also modify /etc/fstab using things like the
> "noatime" parameter.  I will show you how mine looks (i'll attach a
> screenshot).
> You will also notice my partition map - everything was divided on
> install. seperate /home, /usr , /var, /tmp and of course / (root).
> this way i can specify different parameters and most importantly home
> and root are seperate!
> 
>  The end result is good though:
> 
> Dell Inspiron 6400
> CoreDuo 1.6ghz
> 1 gig RAM
> ATI x1300
> IntelHDA
> 320gig 5400 rpm HDD
> 
> In the case of Jackd, will have 128 frames with a period of 2.   I
> could run say Ardour with 10-20 tracks, no xruns. I can run many VST
> instruments (using wine) with FX chains, or substantial routings, and
> the only xruns i will get are usually on startup of a given plugin.
> 
> When i am doing post-production, i simply change the frames to 1024,
> then ardour with a boat load or plugins, still wont cause xruns.  In
> my case it has worked out really well.  I am currently using:
> 
> 2.6.35-zen2+
> 
> which works better than the planet CCRMA rt-kernel.  it also works
> better than the puppy linux rt-kernel and better than ubuntu's
> rt-kernel on my hardware. this crappy old dell, actually works quite
> nicely for pro-audio and i have squeezed out a lot of extra
> performance.  I will have to think about what else i am using in the
> kernel that may boost performance, but this should give you a decent
> start.
> 
> Soon this machine will be retired as i only need 2-3 more components
> for my AMD Phenom x4 965 3.40ghz system with 8gig ram DDR3 and a
> 7200rpm HDD - Which will be plenty fast. (especially once i optimize
> it with Open64 compiler).
> 
> if you have any questions, just ask, and again sorry for forgetting
> to
> reply, i have been a busy boy!


It sounds like Jordan is having fun, and that is okay, but for newbies on this list, they should understand that what he is doing, has absolutely nothing to do with the real-time kernel, and the PREEMPT_RT patch.

Thanks

Re: "yum install ...." based instruction on building a RT kernel.

[jordan]

Agreed,

No newbie should be doing these hacks, these were just for Bernardo as
he was looking for an alternative
to RT which he seemed to not be able to get to work on his system properly...

And yes, it isn't realtime linux and the PREEMPT_RT Patch. it is a
different patch set that can provide low latency, some performance
tweaks, that can operate suitably well for pro-audio/media production
on linux, but attained using an entirely different method all
together. Not recommended if you don't understand
what is going on there to some degree... ;)

i wouldn't be using this method, if my laptop wasn't so crappy (buggy hardware).
This is the only method that works well on this computer, and is much
more stable than RT runs...
While still allowing me to accomplish what realtime linux and the
PREEMPT_RT Patch allowed me to do
on this machine, in this kind of use case.

(rt-kernel is ideal)

jordan