Infoportal
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende Überarbeitung | ||
| software:linux:preempt_rt:start [2016-05-26 12:56] – mgehrig2 | software:linux:preempt_rt:start [2023-04-11 09:52] (aktuell) – gelöscht Urs Graf | ||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| - | <box red 100% | Hinweis> Diese Seite ist in Bearbeitung. Marcel Gehrig 26.05.2016 </ | ||
| - | ====== Preempt_RT ====== | ||
| - | ===== Vorwort ===== | ||
| - | |||
| - | <box blue right 22% | **Linux Preempt_RT**> | ||
| - | {{.: | ||
| - | [[https:// | ||
| - | </ | ||
| - | |||
| - | <box 22% right green | **Beispiele für den Bau von RT-Kernel**> | ||
| - | * [[software: | ||
| - | * [[.: | ||
| - | * [[.: | ||
| - | </ | ||
| - | |||
| - | 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. | ||
| - | |||
| - | |||
| - | ===== Realtime Allgemeine Hinweise ===== | ||
| - | Auf der Seite [[.: | ||
| - | |||
| - | |||
| - | ===== Bau von RT Kernel ===== | ||
| - | Siehe grüne Box //" | ||
| - | |||
| - | |||
| - | ===== Messung der RT-Performance ===== | ||
| - | Bei RT Systemen ist die Latenz ein wichtiges Mass. In diesem Zusammenhang wird auch oft von der maximalen Latenz gesprochen. Es ist allerdings nicht ganz einfach die maximale Latenz zu messen. | ||
| - | |||
| - | |||
| - | ==== 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 //" | ||
| - | |||
| - | 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 ==== | ||
| - | Mit dem Cyclictest kann die maximale Latenz gemessen werden. Mehr dazu auf der Seite [[software: | ||
| - | |||
| - | ==== EEROS ==== | ||
| - | EEROS bietet eine Möglichkeit, | ||
| - | |||
| - | |||
| - | ===== Künstliche Belastung für RT-Systeme ===== | ||
| - | Wenn das System nicht unter Realbedinungen gemessen werden kann, kann es künstlich belastet werden. Mehr dazu unter [[.: | ||
| - | |||
| - | ===== Einflüsse auf die Latenz ===== | ||
| - | Diverse Faktoren können die Latenz des Systems negativ beeinflussen. Eine genauere Auflistung inklusive möglicher Massnahmen findet sich auf der Seite [[.: | ||
| - | |||
| - | |||
| - | ===== Links ===== | ||
| - | * [[https:// | ||
| - | * [[https:// | ||
| - | * [[http:// | ||
| - | * [[http:// | ||