Realtime-Kernel von Debian jessie?

[whiizy]

Hallo,

unter Debian wheezy habe ich bislang beste Erfahrungen mit dessen Realtime-Kernel gemacht, um die Latenz einer Audio-Anwendung sehr gering zu halten. Nun habe ich allerdings einen neuen lüfterlosen Rechner auf Basis von Intel Celeron N2930 ("Baytrail") und habe ein Debian jessie darauf installiert. Mit dessen RT-Kernel habe ich nun größte Performance-Probleme. Installierte Version:

Code: Alles auswählen

ii  linux-image-3.14-1-amd64        3.14.7-1             amd64                Linux 3.14 for 64-bit PCs
ii  linux-image-3.14-1-rt-amd64     3.14.7-1             amd64                Linux 3.14 for 64-bit PCs, PREEMPT_RT
ii  linux-image-amd64               3.14+57              amd64                Linux for 64-bit PCs (meta-package)

Erst dachte ich, daß der Rechner zu schwach sein könnte, aber zu meiner Überraschung hat der Standard-Kernel (also die non-rt Variante) schon aus dem Stand dieses Problem nicht. Das Gesamtsystem ist also performant genug, es stimmt nur irgendwas im Zusammenhang mit linux-image-3.14-1-rt-amd64 nicht.

Benutzt hier vielleicht sonst noch jemand den RT-Kernel von jessie und hat Ähnliches beobachtet oder aktuell etwas über Probleme gehört?

P.S.
Vielleicht noch als Zusatzinformation: Soundcard ist eine gewöhnliche Onboard hda-intel ALC283 und die einzige realtime-Optimierung ist bislang die Priorisierung der Gruppe audio in der /etc/security/limits.conf:

Code: Alles auswählen

@audio - rtprio 90
@audio - nice -10
@audio - memlock 500000

... wie sie auch unter wheezy bislang immer gut funktioniert hatte.

[storm]

Performance-Probleme.

Wie kommst du zu der Schlussfolgerung? Sagt dir deine Audio-Anwendung, dass die Latenz hoch ist oder hast du evtl. noch andere Anhaltspunkte (oder Messwerte)?

... wie sie auch unter wheezy bislang immer gut funktioniert hatte.

Naja, ich glaub auch nicht, dass es einen Unterschied macht, aber erste Performance-Analysten-Pflicht wäre es, solche Tweaks mal probehalber auszuschalten.

[whiizy]

Performance-Probleme.

Wie kommst du zu der Schlussfolgerung? Sagt dir deine Audio-Anwendung, dass die Latenz hoch ist oder hast du evtl. noch andere Anhaltspunkte (oder Messwerte)?

... wie sie auch unter wheezy bislang immer gut funktioniert hatte.

Naja, ich glaub auch nicht, dass es einen Unterschied macht, aber erste Performance-Analysten-Pflicht wäre es, solche Tweaks mal probehalber auszuschalten.

@storm:
Ja, stimmt schon, ich wollte jetzt nicht sofort zu sehr ins Detail gehen und es nur auf Realtime-Audio verengen. Sollte es ein Problem mit diesem aktuellen RT-Kernel geben, könnte es sich ja auch bei anderen Anwendungsfällen schon gezeigt haben. Und das Thema ist allgemein schon recht exotisch.

Zu Deinen Rückfragen:
Zum Vergleich habe ich jessie jeweils mit dem RealTime- oder dem Mainstream-Kernel gestartet. Das Basissystem ist also identisch (auch die limits.conf). Wenn ich dann meine Piano-Simulation an der command-line starte, wird bei beiden Kerneln die Nutzung von real-time scheduling gemeldet:

Code: Alles auswählen

Multi-core: got real-time scheduling with priority 65

Die verkehrte Welt ist nun, daß der Kernel mit PREEMPT_RT Patch alle Performance-Indices des Applikation verschlechtert. Der Offensichtlichste ist schlicht, daß hörbare Aussetzer beim Spielen entstehen. Der errechnete Performance-Index der Applikation fällt sogar auf etwa die Hälfte des Standard-Kernels. Der kontinuierlich in einer Kurve dargestellte 'Audio load' geht sehr oft an 100% und in den roten Bereich. Das abgespielte Demo-MIDI-file war bei beiden Kerneln identisch und die Leistungsfresser Delay und Reverb abgeschaltet. Die Ausgabe erfolgt direkt an alsa und nicht an irgendwelche soundserver.

Wenn ich die drei realtime-Optionen auskommentiere ...

Code: Alles auswählen

#@audio - rtprio 90
#@audio - nice -10
#@audio - memlock 500000

... fällt das der Applikation beim Start sofort unangenehm auf:

Code: Alles auswählen

Alsa thread could not acquire real-time scheduling, error 1 -- Operation not permitted
Midi thread could not acquire real-time scheduling, error 1 -- Operation not permitted
Multi-core: could not acquire real-time scheduling, error 1 -- Operation not permitted

Realtime-scheduling gibt es dann wohl nicht. Was mich wundert, daß auch der Standard-Kernel auf diese RT-Optionen reagiert. Meine vage Vermutung ist, daß in diesen "normalen" Kernel bereits RT-Patches eingeflossen sein könnten und er bereits deshalb schon so gut funktioniert. Das erklärt aber nicht, warum andererseits der dedizierte rt-Kernel neuerdings so mies (bei mir) performt. Wie gesagt, auf anderen Systemen mit wheezy lief der rt-kernel immer klasse.
Die Optionen aus der limits.conf stammen übrigens aus einer README der Applikation.

Nochmal genauer die betroffene Version:

Code: Alles auswählen

$ cat /proc/version
Linux version 3.14-1-rt-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-3) ) #1 SMP PREEMPT RT Debian 3.14.7-1 (2014-06-16)

Gruß

[storm]

Realtime-scheduling gibt es dann wohl nicht. Was mich wundert, daß auch der Standard-Kernel auf diese RT-Optionen reagiert.

Es sind ja keine RT-Optionen, sondern Optionen, die jedem normalen Prozess die Möglichkeiten einräumen, mit Prioritäten/Rechten zu laufen, die er für realtime braucht, auch mit dem Standard-Kern. Und wenn der Standard-Kernel besser läuft, dann bleib einfach bis auf weiteres bei dem.

[schorsch_76]

Dann lass doch mal die rt-tests laufen. [1][2] und lass dir ein Histogramm erstellen

Ein erster Test.

Code: Alles auswählen

./cyclictest -a -t -n -p99

Das nutzt den nanosec. Timer, RT Prio 99. Lies dir auch [3] durch. Schau dir [4] an.

[1] https://www.osadl.org/Realtime-Preempt- ... estingtool
[2] http://mindlinux.wordpress.com/2013/10/ ... wand-sony/
[3] http://debianforum.de/forum/viewtopic.p ... st#p963634
[4] www.youtube.com/watch?v=f_u4r6ehZKY

[whiizy]

Puh, ein "weites Feld", danke fuer die Links! Habe noch nicht alles gesichtet (insbesondere das Video), weil ich aufgrund SSD-Einbau das Laptop nochmal komplett neu aufgesetzt habe. Mein Problem mit dem RT kernel bleibt aber wie erwartet erhalten.

Zum Einstieg habe ich erstmal Deinen genannten cyclictest aus dem Paket rt-tests aufgerufen:

$ cyclictest -a -t -n -p99
FATAL: timerthread0: failed to set priority to 99

Dessen Scheitern liegt offenbar an dem Parameter '@audio - rtprio 90' in der limits.conf, denn sobald ich cyclictest mit -p kleinergleich 90 aufrufe, bekomme ich vernünftige Ausgaben:

RT kernel:

Code: Alles auswählen

$ cyclictest -a -t -n -p90
policy: fifo: loadavg: 0.12 0.14 0.11 2/309 3695          

T: 0 ( 3692) P:90 I:1000 C:  30597 Min:      3 Act:    5 Avg:    5 Max:      45
T: 1 ( 3693) P:90 I:1500 C:  20398 Min:      3 Act:    5 Avg:    6 Max:     218
T: 2 ( 3694) P:90 I:2000 C:  15298 Min:     18 Act:   23 Avg:   23 Max:     309
T: 3 ( 3695) P:90 I:2500 C:  12238 Min:     16 Act:   24 Avg:   22 Max:     277

(nach ca. 10 Sekunden habe ich diesen Lauf mit Ctrl-C abgebrochen).

Wenn ich es richtig verstehe, ist die rechte Spalte entscheidend, und es hat zumindest in dieser Zeitspanne nie eine größere Latenz, als 309 µs gegeben. Für mich erscheint das zunächst mal gut, weil Latenzen im Millisekunden-Bereich für Piano-Spiel völlig ausreichen.

Beim non-RT Kernel sieht es eigentlich kaum anders aus, allerdings sind hier mal ganz kurz Peaks um die 5000 µs aufgeschnappt worden:

non-RT:

Code: Alles auswählen

$ cyclictest -a -t -n -p90
policy: fifo: loadavg: 0.21 0.14 0.06 1/291 3162          

T: 0 ( 3159) P:90 I:1000 C:  30550 Min:      3 Act:    4 Avg:    8 Max:    5245
T: 1 ( 3160) P:90 I:1500 C:  20367 Min:      4 Act:    5 Avg:    8 Max:     202
T: 2 ( 3161) P:90 I:2000 C:  15274 Min:      6 Act:   20 Avg:  174 Max:     528
T: 3 ( 3162) P:90 I:2500 C:  12220 Min:      4 Act:   21 Avg:  176 Max:    5744

Bei dem Standard-Kernel zu bleiben wäre am Ende natürlich eine Möglichkeit, nur da es bei Musikinstrumenten nicht zu Aussetzern und größeren Latenzen kommen darf, wäre mir der RT Kernel erstmal wesentlich sympathischer. Hat ja auch auf anderen CPUs in der Vergangenheit immer gut geklappt.

Liege ich mit meiner Interpretation des cyclictest denn halbwegs richtig?

Gruß

[schorsch_76]

Prinzipiell hast du recht. Die rt-prio in der limits.conf begrenzt dich. Ein 10 sec Test ist nicht wirklich aussagekräftig, noch dazu ohne Last.

Interesant und aussagekräftig wird es wenn du richtig heftige Last erzeugst.

dohell.sh (der Name ist Programm) : Erzeugt massive IO und IRQ Last

Code: Alles auswählen

#!/bin/sh
while true; do dd if=/dev/zero of=bigfile bs=1024000 count=1024; done &
while true; do killall hackbench; sleep 5; done &
while true; do hackbench 20; done &
ping -l 100000 -q -s 10 -f v &
while true; do du / ; done

dokernelhell.sh : Erzeugt massive CPU Last und IO Last

Code: Alles auswählen

#!/bin/sh
while true; do cd /usr/src/linux; make -j12; make clean; done &

und in einer dritten Shell

Code: Alles auswählen

#!/bin/sh
CT=/usr/src/rt-tests/cyclictest
$CT -l10000000 -m -n -a0 -t1 -p99 -i200 -h1000 -q > ~/p99-t1-i200.txt
$CT -l10000000 -m -n -a0 -t2 -p99 -i200 -h1000 -q > ~/p99-t2-i200.txt
$CT -l10000000 -m -n -a0 -t3 -p99 -i200 -h1000 -q > ~/p99-t3-i200.txt
$CT -l10000000 -m -n -a0 -t4 -p99 -i200 -h1000 -q > ~/p99-t4-i200.txt
$CT -l10000000 -m -n -a0 -t5 -p99 -i200 -h1000 -q > ~/p99-t5-i200.txt
$CT -l10000000 -m -n -a0 -t6 -p99 -i200 -h1000 -q > ~/p99-t6-i200.txt
$CT -l10000000 -m -n -a0 -t7 -p99 -i200 -h1000 -q > ~/p99-t7-i200.txt
$CT -l10000000 -m -n -a0 -t8 -p99 -i200 -h1000 -q > ~/p99-t8-i200.txt

Der obige Test macht 10 Mio Zyklen bei 200 µs interval => 1e7 * 200e-6 / 60 sec/min => 33 min .
Diese Texttabellen kannst du am Ende in ein gnumeric/LO/OO Calc Sheet packen und das Histogramm anzeigen lassen. Dann weist du mehr... Ein gutes System sieht so aus wenn obige "dohell" scripts laufen: 37871

Wie du hier siehst sind hier alle Ticks unter 32 µs.

Deine 300µs werden vermutlich durch CPU Scaling verursacht. Schalte mal das CPU scaling ab und teste nochmal. Das A und O ist ACPI aus und CPU Scaling abschalten!

[whiizy]

Hallo schorsch_76,

vielen Dank für Deine lehrreichen Tips! Mittlerweile habe ich eine praktikable Lösung gefunden.

Unter jessie ist der default scaling_driver intel_pstate und nicht mehr acpi-cpufreq. Desweiteren benutzt intel_pstate unter jessie per default den scaling_governor powersave, welcher für meine Echtzeitanwendung zu weit runtertaktet. Der RT Kernel kommt mit dem neuartigen intel_pstate bei mir gar nicht zurecht, wie in der Eröffnung beschrieben.

Dafür rennt der ganz normale jessie Kernel aber wie 'ne Eins, wenn ich unter intel_pstate den governor performance auswähle! (und die limits.conf anpasse). Es besteht daher für mich persönlich nun keine Notwendigkeit mehr, auf den RT Kernel auszuweichen.

Gleichwohl habe ich noch eine Möglichkeiten gefunden, wie man auch den RT Kernel wieder ins Spiel bringen kann. Wenn man intel_pstate im Kernel abschaltet (kernel-option intel_pstate=disable), dann wird wieder der alte scaling_driver acpi-cpufreq benutzt und die bisherigen Optimierungsmöglichkeiten stehen dann wieder zur Verfügung. Damit habe ich mich diesmal aber nicht mehr weitergehend beschäftigt, da wie gesagt bereits mit dem Standard-Kernel nun die Latenz und der Audioload hervorragend geworden sind.

Gruß