Hallo Fernando
I guess the following has been asked before. however I would
just like to be sure:
Starting with a naked disk drive and installing Fedora 21 from
the JAM spin, and then installing kernel-rt from the planetcore
repo, would the rt-kernel be automatically started with the
threadirqs parameter? How to check this?
Happy new year, Simon
__________________________________
Simon Lewis
Groß-Gerauer-Straße 84
55130 Mainz
Germany
Tel.: +49 6131 5864787
E-Mail: simon.lewis@slnet-online.de
Am 31.12.2014 um 22:23 schrieb Fernando Lopez-Lezcano:
Sigh:
"This is exactly what the real-time patch is doing: it provides
a mechanism for aggregating the audio tasks, and for attributing
them a higher priority than the other tasks."
No, definitely not, this is NOT what the real-time patch does.
ANY KERNEL CAN DO THIS, you do not need to patch it at all.
As usual - I see this frequently - the writer confuses two
different mechanisms (or layers?) that contribute to audio apps
having good performance for low latency settings:
1) giving user tasks access to SCHED_FIFO and/or SCHED_RR
scheduling. What does this mean? The audio threads in your audio
applications will be able to run in this scheduling ring and
will preempt any other processes in the computer (that is, the
audio threads have priority over everything else). This can be
done with /etc/limits.d/* (the current solution) or cgroups
(newer, only available in newer kernels). Both limits.conf and
cgroups can do the same thing - cgroups can also reserve some
CPU for non-audio tasks (could be a bad thing, could be a good
thing, it depends on your goals).
If this is not done you will not get good performance out of
audio apps, period. And an RT patched kernel will not help at
all.
2) running a kernel that has good low latency performance. There
is a whole range of options for this. The simplest is to enable
full preemption in a vanilla kernel. What does this do? It tries
to minimize the time the kernel spends in critical sections of
code within which scheduling is forbidden. If you can't schedule
an audio task for a "long" time you will get a click as the
sound card is starved of samples. These options can have a small
but probably measurable impact in overall performance (ie:
nothing is free).
A step further is to boot the kernel with the threadirqs
parameter _and_ properly optimize the priorities of the IRQ
kernel threads (the rtirq package does that). What does this do?
It makes sure that the interrupt request of the sound card is
processed with higher priority than (almost) all the others. The
processing of the IRQ will trigger the scheduling of the
userland task that handles the audio samples, so it is important
to do this as well (and the priorities of the IRQ handling
routines and the userland audio threads - jack, for example -
have to be properly ordered).
Going further you tinker with the kernel itself by patching it
so that more of it can be preempted (the type of kernel I
maintain for Planet CCRMA). This is the RT patch which is
maintained separately from the vanilla kernel. It significantly
lowers the time the kernel spends in critical sections of code
that can stop scheduling of tasks. The smaller that time, the
faster an audio task will be scheduled after the sound card
signals the system it has (or needs) samples.
As there are less users actively using the RT patch there are
more bugs. Also, the RT patch has in the past uncovered bugs in
the mainline code that only showed up with the RT patch.
In the past years code from the RT patch has slowly migrated to
the vanilla kernel, so that the maximum latency of a properly
configured vanilla kernel has gone down significantly.
This is all further complicated by hyperthreading (fake cpu
cores) and the newest intel_pstate power budget cpu core speed
control driver. You need to optimize those things as well. For
best performance (or even decent performance) you will have to
enable full speed on all cpu cores, and very likely disable
hyperthreading as well. I used to not notice a difference with
hyperthreading, but in my latest hardware I really need to do
that.
And on some hardware (usually laptops) you are dead in the
water, the BIOS can have badly designed MSI(sp?) handlers that
tie up the CPU for milliseconds and screw up everything that
Linux can try to do. Nothing can be done save for complaining to
the vendor and upgrading the BIOS.
Anyway, hopefully this was a clear explanation...
I'm smart enough to get what they're
doing, but not smart enough to know
if this is what we're already doing in Fedora or how it'll
affect other
security concerns.
----
$ grep PREEMPT /boot/config-3.17.4-200.fc20.x86_64
# CONFIG_PREEMPT_RCU is not set
CONFIG_PREEMPT_NOTIFIERS=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
----
So we do not have CONFIG_PREEMPT set. The Fedora kernel is not
optimized for low latency operation. See:
https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions
for some of the options available (PREEMPT_VOLUNTARY is the
lowest possible optimization).
Also the settings listed
for /etc/security/limits.conf is setting you up for a bad
time.
They said they could get less than 1ms with no xruns (except
at
application startup) which sounds promising. Certainly if
we're shooting
for less than 5 ms instead of less than 1ms.
The statement in that page regarding performance is, well,
meaningless. It does not state what hardware is used. It also
says that it gets xruns "only at application startup" (which
application? under which conditions?).
If you are running a properly tuned system and the audio
applications are properly coded - a big if - then you should
never[*] get xruns. If you get them sometimes it means that,
well, your system is not useful for low latency work. The
question would be: do you get the same performance if you _load_
your system? Can you play at 16x2 without xruns while reading
email, browsing the web and copying a file tree with rsync? Even
when all CPU cores are cranking up at 60-70% utilization? If the
answer is yes then you are in business...
-- Fernando
[*] never does not really really mean never, if the load of the
computer is really really high then at some point you will run
out of CPU and you will get an xrun. At that point you need to
get a faster computer :-)
_______________________________________________
music mailing list
music@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/music