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.4.109preempt-rt patchPREEMPT_NONE (preempt-rt Patch nicht erforderlich)Zum Zeitpunkt der Erstellung dieses Artikels war nur ein Patch gegen Upstream 5.4.106 verfügbar. Leider stürzt der CAN-Treiber damit ab. Dies wurde in Upstream 5.4.109 behoben. Der Patch 5.4.106 wurde ohne Probleme auf 5.4.109 angewendet und hier verwendet.
5.4.109preempt-rt patchPREEMPT_VOLUNTARY
(preempt-rt Patch nicht erforderlich)
siehe oben
5.4.109preempt-rt patchPREEMPT (preempt-rt Patch nicht erforderlich)siehe oben
5.4.109preempt-rt patchPREEMPT_RT (preempt-rt Patch erforderlich)siehe oben
5.4.109Ipipe PatchPREEMPT_NONE (spielt aber keine Rolle, da wir Xenomai darauf ausführen werden) Zum Zeitpunkt der Erstellung dieses Artikels war nur ein Patch gegen Upstream 5.4.107 verfügbar. Leider stürzt der CAN-Treiber damit ab. Dies wurde in Upstream 5.4.109 behoben. Der 5.4.107-Patch konnte nicht direkt auf 5.4.109 angewendet werden, aber er wurde so angepasst, dass er angewendet werden kann.

cyclictest

Wie bereits oben erwähnt, werden wir cyclictest für unsere Benchmarks verwenden. Wir werden zwei Versionen von cyclictest benötigen. Wir kompilieren eine unter Standard-Linux und die andere unter Xenomai. Für die folgenden Diagramme haben wir versucht, einen Prozess mit hoher Priorität periodisch alle 500 Mikrosekunden laufen zu lassen und den Jitter zu messen.

stress-ng

Wir werden stress-ng verwenden, 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. Die Ergebnisse sind in den Diagrammen auf der rechten Seite zu sehen.

PREEMPT_NONE

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_VOLUNTARY

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

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

PREEMPT_RT ist hier das Scheduler-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.

Xenomai

Wir verwenden hier eine spezielle Version von cyclictest, die gegen Xenomai gebaut wurde. Das bedeutet, dass das hier konfigurierte Preemption-Modell für den Testfall irrelevant ist. Cyclictest läuft nicht über den Linux-Scheduler.

Damit dies funktioniert, müssen wir zunächst den Linux-Kernel mit dem Ipipe-Patch patchen. Anschließend muss die Userspace-Anwendung für Xenomai angepasst werden.

Die Verbesserung des maximalen Jitters ist ziemlich gut und typischerweise um einen Faktor zwei besser als bei preempt-rt. Der Nachteil von Xenomai im Vergleich zu preempt-rt ist, dass preempt-rt die einzige Echtzeit-Linux-Lösung ist, die zu kernel.org upstreamed werden kann.

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.

Einen ähnlichen Blog-Beitrag über den Linux-Kernel 5.10, aber auch Testfälle mit Release- und Debug-Kerneln finden Sie hier. Einen Blog-Beitrag über das Yocto Project® Kernel-Tooling finden Sie hier. Wenn Sie mehr darüber erfahren möchten, 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.