| Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende ÜberarbeitungLetzte ÜberarbeitungBeide Seiten der Revision |
| software:linux:preempt_rt:start [2016-05-24 14:20] – mgehrig2 | software:linux:preempt_rt:start [2018-04-13 18:48] – mgehrig2 |
|---|
| <box red 100% | Hinweis> Diese Seite ist in Bearbeitung. Marcel Gehrig 24.05.2016 </box> | |
| |
| ====== Preempt_RT ====== | ====== Preempt_RT ====== |
| ===== Vorwort ===== | ===== Vorwort ===== |
| {{.:preemptrtlogo.png|Preempt_RT}} | {{.:preemptrtlogo.png|Preempt_RT}} |
| [[https://rt.wiki.kernel.org/index.php/Main_Page | Projektwebseite]] | [[https://rt.wiki.kernel.org/index.php/Main_Page | Projektwebseite]] |
| </box> | |
| |
| <box 22% right green | **Beispiele für den Bau von RT-Kernel**> | |
| * [[software:linux:phyCORE-MPC5200B:Kernel_v4_4_15RT | v4.1.15-rt17+ (Real-time) für phyCORE-MPC5200B]] | |
| * [[.:kernel_V3.18.29rt30 | v3.18.29rt30 (Real-time) für x86]] | |
| * [[.:RealtimeDebian | v3.14.18-rt9 (Real-time) Debian-Way]] | |
| </box> | </box> |
| |
| Preempt_RT ist ein von Ingo Molnar betreuter Patch für den Linux Kernel. Dieser modifiziert den Kernel so, dass dieser (beinahe) vollständig präemptiv wird. Dazu werden die klassischen Kernel Spinlocks durch Mutexe ersetzt, welche Prioritätsvererbung unterstützen. Ausserdem wird die Behandlung aller Interrupts in eigene Kernel-Threads ausgelagert. | Preempt_RT ist ein von Ingo Molnar betreuter Patch für den Linux Kernel. Dieser modifiziert den Kernel so, dass dieser (beinahe) vollständig präemptiv wird. Dazu werden die klassischen Kernel Spinlocks durch Mutexe ersetzt, welche Prioritätsvererbung unterstützen. Ausserdem wird die Behandlung aller Interrupts in eigene Kernel-Threads ausgelagert. |
| | Die Präsentation {{:software:linux:preempt_rt:s3r2_jan_altenberg.pdf| Linux und Echtzeit}} von Jan Altenberg bietet eine sehr gute und kurze Zusammenfassung bezüglich den beiden Varianten Preemt RT und Xenomai. |
| |
| | |
| | ===== Realtime Allgemeine Hinweise ===== |
| | Die [[https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions | FAQs]] und die beiden HOWTOs [[https://rt.wiki.kernel.org/index.php/HOWTO:_Build_an_RT-application | HOWTO: Build an RT-application]] und [[https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO | RT PREEMPT HOWTO]] des [[https://rt.wiki.kernel.org/index.php/Main_Page | Real-Time Linux Wiki]] bieten eine gute Einführung in diverse Aspekte und Probleme von Realtime. Die [[.:hinweise_messung_rt | Hinweise Messung RT]] fassen zusätzlich noch einige Punkte zusammen, die nicht nur bei der Messung der RT-Performance wichtig sind, sondern auch im allgemeinen Umgang mit Realtime. |
| |
| ===== Bau von RT Kernel ===== | ===== Bau von RT Kernel ===== |
| Siehe grüne Box //"Beispiele für den Bau von RT-Kernel"// für diverse Beispiele. | Siehe grüne Box //"Beispiele für den Bau von RT-Kernel"// für diverse Beispiele. |
| | |
| | <box 22% right green | **Beispiele für den Bau von RT-Kernel**> |
| | * [[software:linux:phyCORE-MPC5200B:Kernel_v4_4_15RT | v4.1.15-rt17+ für phyCORE-MPC5200B]] |
| | * [[.:kernel_V3.18.29rt30 | v3.18.29rt30 für x86]] |
| | * [[.:RealtimeDebian | v3.14.18-rt9 Debian-Way]] |
| | * [[.:..:toradex:kernel#Preempt-RT%20Kernel%203.14.28 | v3.14.79 für Colibri iMX6]] |
| | * [[.:bbbrt | v4.4.25-rt35 (Kurztanleitung) für Beaglebone Black]] |
| | </box> |
| |
| |
| |
| ==== Schwierigkeiten bei der Messung der RT-Performance ==== | ==== Schwierigkeiten bei der Messung der RT-Performance ==== |
| Die gemessene Latenz ist abhängig von Tasks und Interrupts die während der Messung auftauchen. Besonders Interrupts und Tasks mit einer höheren Priorität als die RT-Applikation haben einen grossen Einfluss. Aus diesem Grund sollte die Latenz unter realen Bedingungen (möglichst inklusive RT-Applikation und externen Interrupts) gemessen werden. Wenn dies nicht möglich ist, kann das System künstlich belastet werden. Siehe weiter unten im Kapitel //"Künstliche Last"//. | Diverse Hinweise, die beim Messen der RT-Performance beachtet werden solten, sind im Artikel [[.:hinweise_messung_rt | Hinweise Messung RT]] gesammelt. |
| |
| Ein weiterer Faktor ist der Zufall. Einige Interrupts treten nur sehr unregelmässig auf. Andere treten möglicherweise immer genau zwischen periodischen Messungen auf. Um solche Interrupts doch messen zu können, sollte möglichst lange gemessen werden. Mehrere Stunden sind empfehlenswert. Mehrere Tage lange Messungen erhöhen die Chance, Ausreisser zu erwischen. | |
| |
| ==== Cyclictest ==== | ==== Cyclictest ==== |
| | Mit dem Cyclictest kann die maximale Latenz gemessen werden. Mehr dazu auf der Seite [[software:linux:cyclictest:start|Cyclictest]]. |
| |
| ==== EEROS ==== | ==== EEROS ==== |
| Siehe Projektwebseite. (Noch in Arbeit. Marcel Gehrig 24.05.2016) | EEROS bietet eine Möglichkeit, die effektive Latenzen von einer EEROS-Applikation zu messen. Siehe [[http://wiki.eeros.org/for_developers/timing_measurement|Projektwebseite]]. |
| | |
| | ==== Zu erwartende Ergebnisse ==== |
| | Auf der Wiki Seite [[software:linux:cyclictest:start|Cyclictest]] sind bereits einige Ergebnisse dokumentiert. Eine weitere sehr gute Quelle bietet das //Open Source Automation Development Lab// kurz [[https://www.osadl.org|OSADL]]. In ihrer QA Farm werden diverse Prozessoren auf ihre RT Performance getestet. Die Ergebnisse werden veröffentlicht. In der [[https://www.osadl.org/Hardware-overview.qa-farm-hardware.0.html | Hardware Übersicht]] sind alle getesteten Prozessoren aufgelistet. |
| |
| | ===== Künstliche Belastung für RT-Systeme ===== |
| | Wenn das System nicht unter Realbedingungen gemessen werden kann, kann es künstlich belastet werden. Mehr dazu unter [[software:linux:stresstests:start|Künstliche Last]]. |
| |
| ==== Künstliche Last ==== | ===== Einflüsse auf die Latenz ===== |
| === dd === | Im [[https://rt.wiki.kernel.org/index.php/HOWTO:_Build_an_RT-application | HOWTO: Build an RT-application]] sind diverse Einflüsse auf die Latenz aufgelistet. Zusätzlich können noch andere Anwendungen, wie zum Beispiel eine SSH-Verbindung, die Latenz negativ beeinflussen, wenn die Priorität falsch gewählt wird. |
| dd ist ein Linux Befehl, der zum bit-genauen Kopieren von Festplatten, Partitionen oder Dateien dient. Er kann genutzt werden, um eine 100% Prozessorlast zu erhalten. | |
| Folgende Codebeispiele kopieren keine wirklichen Daten und überschreiben auch keine, lasten die CPU aber voll aus. <code>dd if=/dev/zero of=/dev/null</code> | |
| Um mehrere Kerne auszulasten (in diesem Beispiel sind es 4) kann folgender Befehl genutzt werden. <code>fulload() { dd if=/dev/zero of=/dev/null | dd if=/dev/zero of=/dev/null | dd if=/dev/zero of=/dev/null | dd if=/dev/zero of=/dev/null & }; fulload; read; killall dd</code> | |
| Obwohl diese Befehl die CPU voll auslastet, sollten die Ergebnisse des //Cyclictests// nicht beeinflusst werden. | |
| |
| === Cache Calibrator === | [[software:linux:preempt_rt:latenz_reduzieren | Massnahmen um die Latenz / Jitter zu reduzieren]] |
| * [[http://homepages.cwi.nl/~manegold/Calibrator/ | Projektwebseite]] | |
| Der //Cache Calibrator// ist ein kleines C-Programm, dass die Leistung der Caches misst. Bei dieser Messung werden die Caches stark belastet. Der //Cyclictest// soll bei einem RT fähigen System aber trotzdem keine merklich schlechtere Ergebnisse liefern. | |
| == Installation == | |
| * Den [[http://homepages.cwi.nl/~manegold/Calibrator/src/calibrator.c | Quellcode]] herunterladen | |
| * Für die eigene Maschine compilieren <code>gcc calibrator.c -o calibrator -lm</code> | |
| * Für eine andere Maschine cross compilieren <code>//Noch ausstehend//</code> | |
| |
| |
