Zuletzt aktualisiert am 28. Oktober 2023

Anzeige des "Echtzeitgrads" durch Beobachtung des maximalen Jitters von cyclictest über einen Upstream-Kernel

Zielsetzungen

Dieser Beitrag zeigt Ihnen "Echtzeitgrade" durch Beobachtung des maximalen Jitters von cyclictest über einen Upstream-Kernel, der auf verschiedene Weise konfiguriert und gepatcht ist, ohne und mit von stress-ng erzeugter Last.

Voraussetzungen

Kernel/Patches/Konfigurationen

Das sind die Kernel/Kernelkonfigurationen, die wir uns ansehen werden:

Kernel-VersionPatch angewendetSCHED-KonfigurationAnmerkungen
5.10.27keinePREEMPT_NONE RELEASE - Standard-Kernelkonfiguration
5.10.27keinePREEMPT_NONEDEBUG - viele Debugging-Funktionen sind in der Kernel-Konfiguration aktiviert
5.10.27preempt-rt patchPREEMPT_VOLUNTARY
(preempt-rt Patch nicht erforderlich)
RELEASE - Standard-Kernelkonfiguration
5.10.27preempt-rt- patchPREEMPT (preempt-rt Patch nicht erforderlich)RELEASE - Standard-Kernelkonfiguration
siehe oben
5.10.27preempt-rt patchPREEMPT_RT (preempt-rt Patch erforderlich)RELEASE - Standard-Kernelkonfiguration
siehe oben
5.10.27preempt-rt patchPREEMPT_RT (preempt-rt Patch erforderlich)DEBUG - viele Debugging-Funktionen sind in der Kernelkonfiguration aktiviert
siehe oben

cyclictest

Wie bereits oben erwähnt, verwenden wir cyclictest für unsere Benchmarks. Für die folgenden Diagramme haben wir versucht, einen Prozess mit hoher Priorität regelmäßig alle 500 Mikrosekunden auszuführen und den Jitter zu messen.

stress-ng

Wir verwenden stress-ng, um das System unter Stress zu setzen. Das Echtzeitverhalten ist über den Worst-Case-Jitter unter hoher Last sichtbar. Bei den "Last"-Testfällen muss loadavg den Wert "Anzahl der CPUs * 3" erreichen, um die Messung zu beenden.

Jitter-Messungen

Der Worst-Case-Jitter in den Diagrammen auf der linken Seite sieht recht vielversprechend aus. Leider sagt der Jitter in einem "Leerlaufsystem" nicht viel aus. Erst wenn wir das System stark belasten, sind realistischere Worst-Case-Jitter-Werte zu erkennen. Dadurch erhalten wir ein viel besseres Verständnis dafür, wie echtzeitfähig ein System tatsächlich ist. Sie sehen diese Ergebnisse in den Diagrammen auf der rechten Seite. Wenn wir die Release-Version (Standardkonfiguration) und die Debug-Version (mit vielen Debug-Elementen) desselben Kernels vergleichen, sehen wir, dass die Kernel-Konfiguration für den Worst-Case-Jitter entscheidend ist.

PREEMPT_NONE (RELEASE)

PREEMPT_NONE ist hier das Scheduler-Preemption-Modell. Dies ist ohne jegliche Kernel-Patches möglich. Bitte beachten Sie den maximalen Jitter unter Last in der Grafik rechts.

PREEMPT_NONE (DEBUG)

PREEMPT_NONE ist hier das Scheduler-Preemption-Modell. Dies ist ohne jegliche Kernel-Patches möglich. Bitte beachten Sie den deutlichen Anstieg des maximalen Jitters unter Last in der Grafik rechts. Er wird durch Änderungen an der Kernelkonfiguration verursacht.

PREEMPT_VOLUNTARY (RELEASE)

PREEMPT_VOLUNTARY ist hier das Präemptionsmodell. Dies ist ohne jegliche Kernel-Patches möglich. Bitte beachten Sie die Verbesserung des maximalen Jitters unter Last in der Grafik rechts.

PREEMPT (RELEASE)

PREEMPT ist hier das Preemption-Modell. Dies ist ohne jegliche Kernel-Patches möglich. Bitte beachten Sie die Verbesserung des maximalen Jitters unter Last in der Grafik rechts.

PREEMPT_RT (RELEASE)

PREEMPT_RT ist hier das Preemption-Modell. Damit dies funktioniert, müssen wir den Kernel-Patch preempt-rt anwenden. Bitte beachten Sie die Verbesserung des maximalen Jitters unter Last in der Grafik rechts.

PREEMPT_RT (DEBUG)

Bitte beachten Sie den signifikanten Anstieg des maximalen Jitters unter Last in der Grafik auf der rechten Seite. Er wird durch Änderungen an der Kernelkonfiguration verursacht.

Schlussfolgerung

Wie Sie oben sehen können, können wir je nach Kernelkonfiguration und Patch-Level den maximalen Jitter in unserem Testfall reduzieren. Die Diagramme hier sollten Ihnen einen ersten Eindruck von den Möglichkeiten geben, die Sie haben. Für Ihr eigenes, spezifisches Echtzeitproblem müssen Sie höchstwahrscheinlich eigene Testfälle entwickeln. Es ist wichtig zu beachten, dass Sie bei Ihrer Kernelkonfiguration besonders vorsichtig sein müssen, um den Worst-Case-Jitter nicht signifikant zu erhöhen.

Einen ähnlichen Blog-Beitrag mit dem 5.4 Linux-Kernel, aber auch Xenomai-Testfällen finden Sie hier. Wenn Sie etwas über das Yocto Project® Kernel-Tooling lesen wollen, schauen Sie hier. Wenn Sie mehr darüber erfahren wollen, wie Embedded Linux funktioniert und wie Linux mit zusätzlicher Echtzeit funktioniert, schauen Sie hier. Um mehr über das Yocto Project® zu erfahren, schauen Sie hier.

Kommende Veranstaltungen

Unsere 3 Punkte

der Differenzierung

Wir stellen Host- und Zielhardware für alle unsere Kurse zur Verfügung.

Drei oder mehr Personen aus demselben Unternehmen? Wir bieten maßgeschneiderte Privatschulungen an - Beratung inklusive.

Fachexperten entwickeln hochwertige, berufsbezogene, aktuelle und authentische Kursunterlagen.