2 Feb
2009
2 Feb
'09
7:08 p.m.
On Mon, 2009-02-02 at 20:24 +0100, Lars-Erik Helander wrote:
About a week ago building from the git produced a kernel that did not
boot properly, actually it did not even build properly and my own
remedy for the build problem resulted in a kernel that was not able to
boot up properly. However building from the git this weekend produced
a well working kernel. Only problem found is the softirq.c bug that
has been around for a while (it makes USB MIDI keyboards etc not to
work - they are discovered but no MIDI events are received) so I had
to apply a patch for that problem.
Build procedure was very straightforward using the git url I cloned
the git and got myself a complete (already "patched" kernel source
tree) and it was just to do the normal "make oldconfig", "make
menuconfig" ... procedures.
I see, I just tried with no luck. It may be a configuration option that
triggers compile errors (or something else I'm not doing right).
-- Fernando
I have also sucsessfully built and used 2.6.26.8-rt13 with the Slitaz
(www.slitaz.org) distribution (the git kernel also works with that
distribution).
In order to use the kernel with my USB MIDI devices I had to apply the
above mentioned softirq.c patch.
Fernando your elaborate response is highly
appreciated, thanks!!
This was my thought to.
I use "lmms" every now and then. I have never been able to get
"lmms"
to work well with jack so I use it with ALSA as the audio driver. This
works fine though I can not use jack application simultaneously. So in
this case do I have to explicitly give "lmms" SCHED_FIFO and rtprio?
How (using chrt?) ?
If you want you could use chrt. I don't know if lmms is multithreaded,
if so you would/should change into SCHED_FIFO the audio thread. Even
then the application should be well designed, otherwise it could hang
the whole machine.
- Will
"rtirq" make a difference on a non-RT-patched kernel system?
No AFAIK. Non-rt patched kernels do not have irq processes running as
separate SCHED_FIFO threads (which is what is tuned by rtirq).
- Do I
need to assign rtprios explicitly to all my processes
(qjackctl, qsynth, ...) or is that "automagic"?
Automagic. Jackd gives the proper priority to the clients (to the thread
of the client that handles audio i/o)
I have close to 30 years experience in developing
realtime systems and
has been using Linux for audio in various distribution the last two
years. Further I have built RT-kernel for couple of distributions
(this weekend I successfully built and ran a 2.6.28-rt kernel from the
new git tree :) ).
Ah, I have not tried this yet! How did that work out? Any errors or
problems on boot? How exactly did you go about building the whole thing?
However I have no experience in using newer non-RT
kernels but I am very interested to find out how well you can have
them work, especially since whenever you find a nice distro you can
not use it because the hazzle of building an RT-kernel for that
particular distro is so big :(.
Planet CCRMA (http://ccrma.stanford.edu/planetccrma/software/) has rt
patched kernels of the 2.6.26.8* flavor for fc9 (in the "testing"
repository) and fc10, and should be easy to install (not an objective
assessment, I created and maintain Planet CCRMA :-). 
3 Feb
3 Feb
11:04 a.m.
New subject: [LAU] Are RT-patches needed anymore? (Was Re: >= 2.6.27 RT ETA?)
Il giorno Mon, 02 Feb 2009 15:07:58 -0800
Fernando Lopez-Lezcano <nando(a)ccrma.Stanford.EDU> ha scritto:
Hi all,
I tried lmms using alsa output with SCHED_RR[1] (chrt) and reniced I/O
(cfq, iorenice) and I found out cpu usage (the one reported by lmms)
dropped significantly. After rescheduling many tracks that used 100%
cpu and still clicked got to play nicely with little cpu usage. System
stability had no issues. LMMS is already threaded and threading support
is improving with 0.4.x versions[2].
Having made some experiments with realtime scheduling and after reading
your words I'll try asking some questions someone here could perhaps
answer:
- what's the difference between running some app realtime, say
"jackd -R", as opposed to "chrt -r" that same app?[3]
- how can I identify the audio thread and change scheduling/nice
priority of that single thread?
- given audio threads already are highest priority, isn't it better to
also schedule SCHED_RR all audio processes (with lower priority than
jackd and other audio threads) so no other process can eat cpu time
up?
- apart from irq threads, is there any other big improvement a -rt
kernel gives over "vanilla"[4] ones?
- does enabling "preempt RCU" make a big difference?
Sorry if some questions are trivial or already got answered somewhere
else, I looked around and found nothing relevant concerning these
questions. I'm not a kernel expert and just digging my way trying
to learn.
Bye, Nicola.
[1] imho SCHED_RR is better than SCHED_FIFO
[2]
http://sourceforge.net/mailarchive/message.php?msg_name=200902020056.29654.…
[3] it seems to me that using chrt to reschedule a process just
reschedules one thread, while lanching the same app scheduled with
chrt -r in the first place gets all threads scheduled realtime.
[4] I use "stock" debian kernels reconfigured with forced
preemption (low-latency desktop) and 300Hz timer and get pretty low
latency (1.5ms) with no xruns at all even under heavy desktop usage
I use
"lmms" every now and then. I have never been able to get
"lmms" to work well with jack so I use it with ALSA as the audio
driver. This works fine though I can not use jack application
simultaneously. So in this case do I have to explicitly give "lmms"
SCHED_FIFO and rtprio? How (using chrt?) ?
If you want you could use chrt. I don't know if lmms is multithreaded,
if so you would/should change into SCHED_FIFO the audio thread. Even
then the application should be well designed, otherwise it could hang
the whole machine.
2:11 p.m.
New subject: [LAU] Are RT-patches needed anymore? (Was Re: >= 2.6.27 RT ETA?)
On Tue, 2009-02-03 at 16:04 +0100, dieeasy wrote:
Il giorno Mon, 02 Feb 2009 15:07:58 -0800
Fernando Lopez-Lezcano <nando(a)ccrma.Stanford.EDU> ha scritto:
Hi all,
I tried lmms using alsa output with SCHED_RR[1] (chrt) and reniced I/O
(cfq, iorenice) and I found out cpu usage (the one reported by lmms)
dropped significantly. After rescheduling many tracks that used 100%
cpu and still clicked got to play nicely with little cpu usage. System
stability had no issues. LMMS is already threaded and threading support
is improving with 0.4.x versions[2].
Having made some experiments with realtime scheduling and after reading
your words I'll try asking some questions someone here could perhaps
answer:
- what's the difference between running some app realtime, say
"jackd -R", as opposed to "chrt -r" that same app?[3]
Jack will give SCHED_FIFO to just the audio thread of the client
application (which is normally the only one that actually needs that).
I use
"lmms" every now and then. I have never been able to get
"lmms" to work well with jack so I use it with ALSA as the audio
driver. This works fine though I can not use jack application
simultaneously. So in this case do I have to explicitly give "lmms"
SCHED_FIFO and rtprio? How (using chrt?) ?
If you want you could use chrt. I don't know if lmms is multithreaded,
if so you would/should change into SCHED_FIFO the audio thread. Even
then the application should be well designed, otherwise it could hang
the whole machine. - how can I identify the audio thread and change
scheduling/nice
priority of that single thread?
I don't think you can. You can see the threads and their pids
in /proc/PID/task/ but you don't know which is which. They are just
numbers.
I pays to have jack applications that are properly designed. Then you
don't have to worry about scheduling and priorities (in a properly
configured system).
- given audio threads already are highest priority,
isn't it better to
also schedule SCHED_RR all audio processes (with lower priority than
jackd and other audio threads) so no other process can eat cpu time
up?
Audio threads should be the only ones that need realtime scheduling.
What do you mean by "all audio processes"?
- apart from irq threads, is there any other big
improvement a -rt
kernel gives over "vanilla"[4] ones?
The time kernel system calls spend in a non-preemptible state are
supposed to be lower than in a stock kernel (but the gap has been
getting narrower). That means that a process that is ready to run and
has SCHED_FIFO has a better chance of being scheduled in time, in the
stock kernel there could be delays in scheduling that cause the process
to be scheduled too late... (and you get an xrun)
- does enabling "preempt RCU" make a big
difference?
I have no idea...
Sorry if some questions are trivial or already got
answered somewhere
else, I looked around and found nothing relevant concerning these
questions. I'm not a kernel expert and just digging my way trying
to learn.
Bye, Nicola.
[1] imho SCHED_RR is better than SCHED_FIFO
SCHED_RR will be preempted when it uses up its time slice. That prevents
lockups but it means you could get an xrun anyway.
[2]
http://sourceforge.net/mailarchive/message.php?msg_name=200902020056.29654.…
[3] it seems to me that using chrt to reschedule a process just
reschedules one thread, while lanching the same app scheduled with
chrt -r in the first place gets all threads scheduled realtime.
I would assume that's how it works.
You don't want the whole app to be SCHED_FIFO, that would mean that, for
example, screen updates would potentially starve the audio threads.
[4] I use "stock" debian kernels
reconfigured with forced
preemption (low-latency desktop) and 300Hz timer and get pretty low
latency (1.5ms) with no xruns at all even under heavy desktop usage
Latest kernels are known to be pretty good without the rt patch. Is this
2.6.28.*?
-- Fernando
4 Feb
4 Feb
4:42 a.m.
New subject: [LAU] Are RT-patches needed anymore? (Was Re: >= 2.6.27 RT ETA?)
Il giorno Tue, 03 Feb 2009 10:11:20 -0800
Fernando Lopez-Lezcano <nando(a)ccrma.Stanford.EDU> ha scritto:
What I meant there was (if I got how it works right):
- jackd already manages audio thread priority, which get SCHED_FIFO
and therefore can preempt every other process/thread in the system
- all other processes are sheduled SCHED_OTHER with various nice levels
So, isn't it better to schedule SCHED_RR audio processes (say lmms,
hydrogen and zynaddsubfx) so a cronjob, xorg, daemons and such can't
possibly preempt audio processes?
I think such a situation (i.e. a cronjob preempting zynaddsubfx)
would not give you xruns, but it could lead to audio dropouts
(zynaddsubfx not having time to process audio), which is as bad as xruns
'cause you lose your sound.
Same goes for any other setup in which some apps aren't connected to
jack or properly designed.
Yep, I run 2.6.28.
Thank for your reply, I've made my mind clearer on some interesting
points now.
bye,
Nicola.
- what's
the difference between running some app realtime, say
"jackd -R", as opposed to "chrt -r" that same app?[3]
Jack will give SCHED_FIFO to just the audio thread of the client
application (which is normally the only one that actually needs
that).
- how can I identify the audio thread and change
scheduling/nice
priority of that single thread?
I don't think you can. You can see the threads and their pids
in /proc/PID/task/ but you don't know which is which. They are just
numbers.
I pays to have jack applications that are properly designed. Then you
don't have to worry about scheduling and priorities (in a properly
configured system).
- given audio threads already are highest
priority, isn't it better
to also schedule SCHED_RR all audio processes (with lower priority
than jackd and other audio threads) so no other process can eat cpu
time up?
Audio threads should be the only ones that need realtime scheduling.
What do you mean by "all audio processes"? SCHED_RR will be preempted when it uses up its time
slice. That
prevents lockups but it means you could get an xrun anyway.
I imagine this scenario being very close to the machine not having
enough power to fulfill the requested tasks.
If a round robin across all audio threads gives xruns a fifo on jackd's
audio thread would leave other ones with no cpu time left, I guess.
- apart from
irq threads, is there any other big improvement a -rt
kernel gives over "vanilla"[4] ones?
The time kernel system calls spend in a non-preemptible state are
supposed to be lower than in a stock kernel (but the gap has been
getting narrower). That means that a process that is ready to run and
has SCHED_FIFO has a better chance of being scheduled in time, in the
stock kernel there could be delays in scheduling that cause the
process to be scheduled too late... (and you get an xrun)
- does enabling "preempt RCU" make a
big difference?
I have no idea...
[...]
[4] I use "stock" debian kernels
reconfigured with forced
preemption (low-latency desktop) and 300Hz timer and get pretty
low latency (1.5ms) with no xruns at all even under heavy desktop
usage
Latest kernels are known to be pretty good without the rt patch. Is
this 2.6.28.*?
5695
days inactive
5697
days old
linux-audio-tuning@lists.linuxaudio.org
3 comments
2 participants
participants (2)
-
dieeasy -
Fernando Lopez-Lezcano