Autor: Dr. Carsten Emde, Open Source Automation Development Lab (OSADL) eG<\/p>\n
Dem Linuxkernel m\u00f6gliche Echtzeiteigenschaften (RT) zu geben, ist nicht schwer:<\/strong><\/p>\n \u2022\u00a0Kernel herunterladen, Auch die \u00dcberpr\u00fcfung, inwieweit sich das Antwortverhalten des neu hergestellten Kernels tats\u00e4chlich tats\u00e4chlich verbessert hat, ist recht einfach:\u00a0<\/strong>Das Programm\u00a0cyclictest\u00a0<\/em>starten und ein paar Stunden warten &\u00a0<\/strong>Ergebnis beurteilen.<\/strong><\/p>\n Was kann man tun, wenn Latenzen gefunden werden, d.h. wenn der Kernel das Userspace-Programm hin und wieder mal zu sp\u00e4t aufweckt? Hierf\u00fcr gibt es verschiedene Messmethoden; aber ganz so einfach wie die Herstellung des RT-Kernels ist es nun nicht mehr. Daher werden die einzelnen Messmethoden<\/p>\n \u2022 Breaktrace mit anschlie\u00dfender Trace-Analyse im Detail erkl\u00e4rt und mit Beispielen vorgef\u00fchrt. Dar\u00fcber hinaus gibt es h\u00e4ufig vorkommende Latenzquellen wie z.B.<\/p>\n \u2022 Frequenzmodulation und die ausgeschlossen werden m\u00fcssen.<\/p>\n In einem ersten Schritt w\u00e4hlt man Patchlevel und Sublevel des RT-Kernels, dessen Nummer m\u00f6glichst nahe am Kernel der jeweiligen Distribution liegt. Dies ist in der Regel m\u00f6glich, da es mit wenigen Ausnahmen f\u00fcr jeden zweiten Patchlevel einen RT-Patch gibt. Wenn also z.B. die Debian-Distribution 9 (stretch) verwendet wird, kann man durch Eingabe des Kommandos<\/p>\n dpkg -l linux-image-`uname -r`<\/p>\n die Information<\/p>\n ||\/ Name Version erhalten, dass die aktuelle Installation den Linuxkernel in der Version 4, Patchlevel 9 und Sublevel 51 verwendet. Auf der Downloadseite des Linux-RT-Projekts –\u00a0https:\/\/cdn.kernel.org\/pub\/linux\/kernel\/projects\/rt\/4.9\/older\/<\/a>\u00a0– erf\u00e4hrt man dann, dass dort der RT-Patch<\/p>\n patch-4.9.47-rt37.patch.xz<\/p>\n verf\u00fcgbar ist, der dem aktuellen Nicht-RT-Kernel am \u00e4hnlichsten ist. Mit den folgenden Kommandos wird<\/p>\n \u2022 der dazu passende Quellcode heruntergeladen, mkdir -p \/usr\/src\/kernels<\/span> Damit der RT-Kernel die aktuelle Distribution m\u00f6glichst gut unterst\u00fctzt, \u00fcbernimmt man im ersten Schritt deren Kernel-Konfiguration, die sich bei Debian wie bei vielen anderen Distributionen im Verzeichnis\u00a0\/boot\u00a0<\/em>befindet und in der Versionsnummer mit dem Kernel \u00fcbereinstimmt. Im vorliegenden Fall ist es die Datei\u00a0\/boot\/config-4.9.0-4-amd64<\/em>, die nun unter dem Namen .config in das Root-Verzeichnis des Kernel-Quellcodes kopiert wird:<\/p>\n cp \/boot\/config-4.9.0-4-amd64 .config<\/p>\n Im letzten Schritt, bevor der Kernel \u00fcbersetzt werden kann, muss nun der neue Kernel konfiguriert werden, so dass die mit dem RT-Patch eingespielte Funktionalit\u00e4t auch genutzt wird. Dazu wird das Kommando<\/p>\n make menuconfig<\/p>\n aufgerufen, die Seite<\/p>\n Processor type and features —> aufgerufen und\u00a0Fully Preemptible Kernel (RT)\u00a0<\/em>ausgew\u00e4hlt wie in Abbildung 1 (siehe\u00a0PDF<\/a>) ausgef\u00fchrt. Der Kernel wird sodann in \u00fcblicher Weise \u00fcbersetzt, installiert, und das System muss danach neu gestartet werden.<\/p>\n make -j4 Beim Neustart wird dann der RT-Kernel im Boot-Menu ausgew\u00e4hlt.<\/p>\n Als erster wichtiger Schritt nach dem Neustart sollte man sich vergewissern, ob der neue Kernel tats\u00e4chlich \u2013 zumindest formal \u2013 richtig konfiguriert wurde. Dies erkennt man daran, ob die Flags\u00a0PREEMPT\u00a0<\/em>und\u00a0RT\u00a0<\/em>in der Ausgabe des Programms\u00a0uname\u00a0<\/em>enthalten sind:<\/p>\n uname -v | cut -d\u201c \u201c -f1-4<\/span> was hier offensichtlich der Fall ist. Ein viel besserer Beweis ist aber nat\u00fcrlich, asynchron einfallende Ereignisse zu erzeugen und zu \u00fcberpr\u00fcfen, wie lange das System h\u00f6chstens ben\u00f6tigt, damit ein auf dieses Ereignis wartender Userspace-Prozess mit Echtzeit-Priorit\u00e4t darauf reagieren kann. Die zu erwartende Zeitspanne l\u00e4sst sich mit der Faustformel<\/p>\n Maximale Latenz = Taktintervall x 10\u2075<\/p>\n absch\u00e4tzen. Demnach kann man also zum Beispiel bei einem System mit einer Taktfrequenz von 1 GHz und damit einem Taktintervall von 1 ns eine maximale Latenz von weniger als 100 \u03bcs erwarten. F\u00fcr die Messung der maximalen Reaktionszeit eines Userspace-Prozesses hat sich das Testprogramm\u00a0cyclictest\u00a0<\/em>bew\u00e4hrt, das in der RT-Test Suite\u00a0rt-tests\u00a0<\/em>enthalten ist, die vom folgenden Repository bezogen werden kann:<\/p>\n git clone git:\/\/git.kernel.org\/pub\/scm\/utils\/rt-tests\/rttests.git<\/p>\n Das Programm\u00a0cyclictest\u00a0<\/em>enth\u00e4lt auch gleich eine Histogramm-Funktion, mit der sich sogenannte Latenz-Plots in der Standardform herstellen lassen. In dieser Standardform werden auf der\u00a0x<\/em>-Achse Latenzklassen in Mikrosekunden mit einer Granularit\u00e4t von einer Mikrosekunde aufgetragen, und auf der\u00a0y<\/em>-Achse stehen die H\u00e4ufigkeiten an Messungen pro Klasse in logarithmischer Darstellung. Es handelt sich also um ein Histogramm mit der Besonderheit, dass durch die logarithmische\u00a0y<\/em>-Achse sowohl sehr geringe als auch sehr gro\u00dfe H\u00e4ufigkeiten abgelesen werden k\u00f6nnen. Ein Shell-Skript, mit dem sich\u00a0cyclictest\u00a0<\/em>ausf\u00fchren und sich aus den Messwerten unmittelbar ein Standard-Latenzplot erzeugen l\u00e4sst, kann von der OSADL-Webseite unter\u00a0https:\/\/www.osadl.org\/uploads\/media\/mklatencyplot.bash<\/a>\u00a0heruntergeladen werden. Es erfordert die vorherige Installation der Programmpakets\u00a0gnuplot<\/em>, das in den meisten Distributionen enthalten ist. Au\u00dferdem wird ein Programm ben\u00f6tigt, um den vom Skript erzeugten Latenzplot\u00a0plot.png\u00a0<\/em>anzuzeigen.<\/p>\n # 1. Run cyclictest # 2. Get maximum latency # 3. Grep data lines, no empty lines a common field separator # 4. Set the number of cores, for example # 5. Create two-column data sets # 6. Create plot command header # 7. Append plot command data references # 8. Execute plot command Wird das Skript unver\u00e4ndert \u00fcbernommen, so hat es eine Laufzeit von 5 Stunden und 33 Minuten und erzeugt dabei Daten von 100 Millionen Zyklen. F\u00fcr ein aussagekr\u00e4ftiges Ergebnis m\u00fcssen w\u00e4hrend der Messung geeignete Stress-Szenarien eingerichtet werden. Ein typisches Ergebnis ist in Abbildung 2 (siehe\u00a0PDF<\/a>) wiedergegeben; die Skalierung der\u00a0x<\/em>-Achse ist bewusst sehr hoch gew\u00e4hlt, um das Ergebnis mit langsameren Prozessoren bzw. mit Systemen, die unbefriedigende Echtzeiteigenschaften besitzen, vergleichen zu k\u00f6nnen. W\u00fcnschenswert ist eine m\u00f6glichst steile rechtsseitige Flanke der Kurve. Da es sich um einen Prozessor mit einer Taktfrequenz von 2,5 GHz und damit einem Taktintervall von 0,4 ns handelt, w\u00e4re nach oben genannter Faustformel eine maximale Latenz von 40 \u03bcs zul\u00e4ssig. Der hier gemessene Wert in H\u00f6he von 19 \u03bcs liegt deutlich darunter, so dass eine Forschung nach den Ursachen dieser Latenz und der Versuch, deren weitere Reduktion zu erreichen, wohl nicht sinnvoll sind.<\/p>\n Beim in Abbildung 3 (siehe\u00a0PDF<\/a>)wiedergegebenen Latenzplot handelt es sich um ein Uniprozessorsystem mit x86-Architektur. Diese Architektur ben\u00f6tigt nicht selten sogenannte System Management Interrupts (SMIs), mit denen zum Beispiel bestimmte Kommunikations-Protokolle emuliert, thermische Kontrollma\u00dfnahmen organisiert und Microcode-Patche ausgef\u00fchrt werden. Da das Betriebssystem keinerlei M\u00f6glichkeit hat, SMIs zu verhindern, kann es durchaus sein, dass SMIs mit einer Ausf\u00fchrungsdauer, die l\u00e4nger als die akzeptable Latenz des Systems ist, dazu f\u00fchren, dass ein solches System grunds\u00e4tzlich nicht f\u00fcr echtzeitpflichtige Aufgaben eingesetzt werden kann. Mitunter kann eine Nachbesserung des BIOS durch den Hersteller die SMIs beseitigen oder zumindest soweit verk\u00fcrzen, dass diese nicht die Echtzeiteigenschaften des Systems beeintr\u00e4chtigen.<\/p>\n Der Latenzplot in Abbildung 3 (siehe\u00a0PDF<\/a>) legt den Verdacht nahe, dass es sich um SMI-bedingte Latenzen handelt. Um dies n\u00e4her zu \u00fcberpr\u00fcfen, wurde das Programm\u00a0hwlatdetect\u00a0<\/em>verwendet, das genau wie\u00a0cyclictest\u00a0<\/em>in der bereits erw\u00e4hnten RT-Test Suite\u00a0rt-tests\u00a0<\/em>enthalten ist. Ab Kernel-Patchlevel 4.9 kann dieses Programm allerdings nicht mehr verwendet werden, da seit diesem Kernel die Funktionalit\u00e4t im Mainline-Kernel enthalten ist und mit Hilfe des tracing<\/em>-Subsystems verwaltet wird. Unabh\u00e4ngig von der Implementierungs-Variante besteht die Messung aus einer einmal pro Sekunde stattfindenden halbsek\u00fcndigen Halt-Operation des Prozessors, w\u00e4hrend der normalerweise keine Instruktionen ausgef\u00fchrt werden. Passiert dies dennoch, was durch regelm\u00e4\u00dfige Abfrage des\u00a0Time Stamp Counters\u00a0<\/em>des Prozessors festgestellt werden kann, handelt es sich um eine extern ausgel\u00f6ste Aktivit\u00e4t, die zu Latenzen f\u00fchren und deren Dauer bestimmt werden kann. Das Ergebnis einer solchen Hardware-Latenz-Messung kann dann wiederum in Form eines Histogramms dargestellt werden.<\/p>\n In Abbildung 4 (siehe\u00a0PDF<\/a>) erkennt man eine Vielzahl von Hardware-Latenzen, deren Dauer von knapp \u00fcber 300 \u03bcs gut zum Latenzplot des gleichen Systems in Abbildung 3 passt.<\/p>\n Wenn ein System erh\u00f6hte Latenzen aufweist, sich diese aber nicht mit SMIs erkl\u00e4ren lassen, muss versucht werden, die Ursache der Latenzen zu ermitteln. M\u00f6glicherweise gibt es einen anderen Prozess, der mit einer h\u00f6heren Priorit\u00e4t zur Latenz des beobachteten Prozesses f\u00fchrt; es ist aber auch m\u00f6glich, dass eine Systemkomponente f\u00fcr einen zu langen Zeitraum die Bearbeitung von Interrupts oder das Neustarten von Prozessen ausgesetzt hat. W\u00e4hrend ersteres sich in der Regel durch eine Analyse der aktuell laufenden Userspace-Prozesse kl\u00e4ren l\u00e4sst, erfordert letzteres eine Analyse von Kernelprozessen. F\u00fcr eine solche Analyse von Kernelprozessen enth\u00e4lt das bereits erw\u00e4hnte und verwendete Testprogramm\u00a0cyclictest\u00a0<\/em>eine spezielle Option, mit der sich Kernel-Tracing zu Beginn der Operation einschalten und in dem Moment, in dem eine Latenz aufgetreten ist, wieder abschalten l\u00e4sst. Als Argument muss dieser Option, die\u00a0breaktrace\u00a0<\/em>genannt wird, ein Schwellenwert mitgegeben werden, bei dessen \u00dcberschreitung das Kernel-Tracing beendet wird. Wenn sogenanntes\u00a0Function Tracing\u00a0<\/em>als Trace-Methode gew\u00e4hlt wird, muss ber\u00fccksichtigt werden, dass das System dadurch etwa um den Faktor 4 langsamer wird. Dies behindert aber die Suche nach der Ursache einer Latenz nicht grunds\u00e4tzlich, da die Verlangsamung des Systems in der Regel auch zu einer Verl\u00e4ngerung der Latenzen f\u00fchrt.<\/p>\n Das folgende Beispiel geht von einem Mehrkernsystem aus, das eigentlich eine maximale Latenz von unter 100 \u03bcs aufweisen sollte, tats\u00e4chlich aber Latenzen von \u00fcber 1000 \u03bcs gemessen werden. Damit die zu erwartende Latenz unter Ber\u00fccksichtigung des durch das\u00a0Function Tracing\u00a0<\/em>hinzunehmenden Leistungsverlusts des Systems nicht zu einem falsch positiven Abbruch der Messung f\u00fchrt, sollte die Schwelle mehr als viermal h\u00f6her, also zum Beispiel 600 \u03bcs, betragen. Da die zu analysierende Latenz von 1000 \u03bcs deutlich dar\u00fcber liegt, f\u00fchrt diese Schwelle immer noch zum gew\u00fcnschten Messabbruch. Der Aufruf des Programms\u00a0cyclictest\u00a0<\/em>k\u00f6nnte in diesem Fall also lauten<\/p>\n cyclictest -m -Sp90 -i600 -d0 -fb600 und bei Abbruch der Messung durch \u00dcberschreiten der Latenzschwelle w\u00fcrde\u00a0cyclictest\u00a0<\/em>dann die folgende Meldung ausgeben (einzelne Werte zur besseren \u00dcbersicht entfernt):<\/p>\n T: 0 P:90 I:600 C:12049 Min:19 Act: 79 Avg:120 Max: 312 Der Thread mit der PID 18127 wurde offensichtlich mit einer Verz\u00f6gerung von 3,12 ms aufgeweckt, was \u00fcber der Schwelle von 600 \u03bcs liegt. Diese Situation passt gut zu den beobachteten Latenzen. Im n\u00e4chsten Schritt muss dann der Zeitpunkt im KernelTracing aufgesucht werden, an dem der erwartete Start des verz\u00f6gerten\u00a0cyclictest<\/em>-Threads ausgeblieben ist, und es muss die Ursache untersucht werden. Nicht selten liegt es daran, dass ein anderer Prozess zu diesem Zeitpunkt Interrupts gesperrt hat, so dass der Timer-Interrupt des von\u00a0cyclictest\u00a0<\/em>aufgezogenen Timers nicht zur Bearbeitung gelangt. Dieser Programmfehler muss dann behoben werden, weil der gleiche Sachverhalt, der in diesem Fall das Platzhalter-Programm\u00a0cyclictest\u00a0<\/em>getroffen hat, unter Produktionsbedingungen die Bearbeitung eines wichtigen Interrupts behindern und damit zu einem schwerwiegenden Maschinenfehler f\u00fchren k\u00f6nnte.<\/p>\n \u00c4hnlich wie das Programm\u00a0cyclictest\u00a0<\/em>im Userspace die verz\u00f6gerte Ausf\u00fchrung eines Interrupts misst, kann man dies auch im Kernel tun und jedes Mal, wenn ein Timer abl\u00e4uft, die Differenz zwischen geplantem und tats\u00e4chlichem Aufwachzeitpunkt bestimmen und in einem Histogramm speichern. Au\u00dferdem kann man die Zeit zwischen dem Beginn des Scheduling-Vorgangs eines aufzuweckenden Prozesses und dessen tats\u00e4chlichen Ausf\u00fchrungsbeginn messen und ebenfalls in einem Histogramm speichern. Dies gilt auch f\u00fcr die Summe der Dauer der beiden Vorg\u00e4nge, die jeweils in einem dritten Histogramm abgespeichert wird. W\u00e4hrend das Programm\u00a0cyclictest\u00a0<\/em>niemals zusammen mit einem unter Produktionsbedingungen laufenden Echtzeitprogramm ablaufen darf \u2013 zumindest nicht auf dem gleichen Prozessorkern \u2013 kann man die Messung mit den internen Latenz-Histogrammen durchaus parallel laufen lassen und sogar Idle-Bedingungen erfassen. Damit die internen Latenz-Histogramme des Kernels zur Verf\u00fcgung stehen, m\u00fcssen diese konfiguriert und zur Laufzeit eingeschaltet werden. Die Konfiguration erfolgt im Menu\u00a0Kernel Hacking\/Tracers\u00a0<\/em>mit den einzelnen Komponenten\u00a0Scheduling Latency Tracer<\/em>,\u00a0Scheduling Latency Histogram\u00a0<\/em>und\u00a0Missed Timer Offsets Histogram.\u00a0<\/em>Zum Einschalten der Histogramme muss ein Wert ungleich Null im\u00a0enable<\/em>-Verzeichnis in die jeweilige Datei geschrieben werden.<\/p>\n Abbildung 5\u00a0(siehe\u00a0PDF<\/a>) zeigt eine 30-st\u00fcndige Aufzeichnung der Summe von Timer- und Aufwach-Verz\u00f6gerung eines Vierkernsystems; es sind die Maxima aufeinanderfolgender 5-Minuten-Intervalle angegeben. Dies ist m\u00f6glich, weil die internen Latenz-Histogramme des Kernels \u00fcber eine Reset-Funktion verf\u00fcgen, die in diesem Fall alle f\u00fcnf Minuten ausgel\u00f6st wurde. Deutlich erkennt man die sehr niedrige Latenz in der Zeit von 5:10 bis 6:40 Uhr und von 7:10 bis 12:43 und jeweils 12 Stunden sp\u00e4ter, in der die Taktfrequenzen der Prozessoren auf Maximum gestellt und alle Schlafstadien abgeschaltet waren. In der \u00fcbrigen Zeit liegen die Latenzwerte deutlich dar\u00fcber, da es sich in diesem Fall um einen relativ modernen Prozessor (Intel Bay Trail) handelt, der \u00fcber ein breites Spektrum an Energiesparmethoden verf\u00fcgt. Wenn man dem Prozessor erlaubt, diese zu nutzen, muss man als Nebenwirkung eine deutlich verl\u00e4ngerte Latenz bzw. den kompletten Verlust jeglicher Echtzeitf\u00e4higkeit hinnehmen.<\/p>\n Neben den Histogrammen werden auch die Daten der am Scheduling beteiligten Prozesse erfasst, und es werden die Prozesse, die jeweils zur bis dahin h\u00f6chsten Latenz gef\u00fchrt haben zusammen mit Priorit\u00e4ten, Prozess-ID und Latenzen abgespeichert. Auf diese Weise kann es gelingen, den Prozess, Thread oder Treiber zu ermitteln, der in einem bestimmten Fall f\u00fcr eine erh\u00f6hte Latenz verantwortlich ist. Dies erleichtert es in der Regel sehr, den zu Grunde liegenden Fehler zu beheben.<\/p>\n Das Beispiel in Tabelle 1 (siehe\u00a0PDF<\/a>) zeigt eine Auflistung der Scheduling-Daten der acht h\u00f6chsten Latenzen w\u00e4hrend eines Tests mit\u00a0cyclictest<\/em>. Wie man sieht, war in jedem Fall das Programm\u00a0meminfo\u00a0<\/em>f\u00fcr die beobachtete erh\u00f6hte Latenz verantwortlich. Dies ist ein starker Hinweis darauf, dass\u00a0meminfo\u00a0<\/em>einen Kernelaufruf vornimmt, der den Linuxkernel daran hindert,\u00a0cyclictest\u00a0<\/em>in der normalerweise kurzen Zeit von h\u00f6chstens 20 \u03bcs aufzuwecken.<\/p>\n Die weitere Analyse ergab, dass bei diesem Kernel die Konfiguration<\/p>\n CONFIG_SLABINFO<\/p>\n eingeschaltet war und w\u00e4hrend der Messung der Aufruf<\/p>\n cat \/proc\/slabinfo<\/p>\n wiederholt ausgef\u00fchrt wurde. Beim Auslesen der Debugdaten des\u00a0SLAB\u00a0<\/em>Allocators kann der Kernel je nach Speicherbelegung und Speicherkonfiguration f\u00fcr einen l\u00e4ngeren Zeitraum nicht unterbrochen werden. Der folgende Patch sorgt daf\u00fcr, dass diese Kernel-Konfiguration nicht eingeschaltet wird, wenn gleichzeitig Real-Time gew\u00e4hlt ist.<\/p>\n — Nach Einspielen dieses Patches, \u00dcbersetzen des Kernels, Installation und Neustart traten die beobachteten Latenzen selbst bei schnell und h\u00e4ufig wiederholtem Auslesen der virtuellen Dartei\u00a0\/proc\/slabinfo\u00a0<\/em>nicht mehr auf.<\/p>\n Wenn die entsprechende Funktion beim Auslesen von\u00a0\/proc\/slabinfo\u00a0<\/em>mit eingeschaltetem\u00a0CONFIG_SLABINFO<\/em>-Flag in Zukunft an die Erfordernisse des Real-Time-Kernels angepasst sein sollte, kann dieser zur Zeit nur lokal eingesetzte Patch nat\u00fcrlich wieder entfallen.<\/p>\n Carsten Emde blickt auf eine mehr als 25-j\u00e4hrige T\u00e4tigkeit als Software-Entwickler, System-Integrator und Trainer zur\u00fcck. Seine Spezialgebiete sind graphische Bedienoberfl\u00e4chen, maschinelle Bilderkennung und Echtzeit-Betriebssysteme. Seit der Gr\u00fcndung der Open Source Automation Development Lab (OSADL) eG im Jahre 2005 ist er deren Gesch\u00e4ftsf\u00fchrer.<\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Open Source \/ Embedded Software Engineering.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema\u00a0Open Source \/ Embedded Software Engineering steht\u00a0hier\u00a0<\/strong><\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\n
\n<\/strong>\u2022\u00a0RT-Patch herunterladen,
\n<\/strong>\u2022\u00a0RT-Patch einspielen,
\n<\/strong>\u2022\u00a0Kernel \u00fcbersetzen,
\n<\/strong>\u2022\u00a0Computer neu starten und
\n<\/strong>\u2022\u00a0RT-Kernel ausw\u00e4hlen.<\/strong><\/p>\n
\n\u2022 Kontinuierliche Latenzaufzeichnung mit Spitzendetektion<\/p>\n
\n\u2022 Schlafstadien,<\/p>\nRekapitulation: Wie erzeuge ich einen echtzeitf\u00e4higen Linuxkernel \u2013 z.B. auf einem Intel-PC mit einer Standard-Distribution?<\/h2>\n
\n+++-=======================—========
\nii linux-image-4.9.0-4-amd 4.9.51-1<\/span><\/p>\n
\n\u2022 der Patch heruntergeladen,
\n\u2022 die Archive ausgepackt und
\n\u2022 der Patch eingespielt:<\/p>\n
\ncd \/usr\/src\/kernels<\/span>
\nwget https:\/\/cdn.kernel.org\/pub\/linux\/kernel\/v4.x\/linux-<\/span>
\n4.9.47.tar.xz<\/span>
\nwget https:\/\/cdn.kernel.org\/pub\/linux\/kernel\/projects\/rt\/<\/span>
\n4.9\/older\/patch-4.9.47-rt37.patch.xz<\/span>
\ntar xf linux-4.9.47.tar.xz<\/span>
\nmv linux-4.9.47 linux-4.9.47-rt37<\/span>
\ncd linux-4.9.47-rt37<\/span>
\nxz -d ..\/patch-4.9.47-rt37.patch.xz<\/span>
\npatch -p1 <..\/patch-4.9.47-rt37.patch<\/span><\/p>\n
\nPreemption Model —><\/p>\n
\nmake modules_install install
\nreboot<\/p>\n\u00dcberpr\u00fcfung des Antwortverhaltens des Systems<\/h2>\n
\n#1 SMP PREEMPT RT<\/span><\/p>\n
\ncyclictest -l100000000 -m -Sp90 -i200 -h400 -q >output<\/p>\n
\nmax=`grep „Max Latencies“ output | tr “ “ “ “ | sort -n | tail -1 | sed s\/^0*\/\/`<\/p>\n
\ngrep -v -e „^#“ -e „^$“ output | tr “ “ “ “ >histogram<\/p>\n
\ncores=4<\/p>\n
\nfor i in `seq 1 `
\ndo
\ncolumn=`expr 1 + 1`
\ncut -f1, histogram >histogram1
\ndone<\/p>\n
\necho -n -e „set title \\“Latency plot\\“ \\
\nset terminal png \\
\nset xlabel \\“Latency (us), max us\\“ \\
\nset logscale y \\
\nset xrange [0:400] \\
\nset yrange [0.8:*] \\
\nset ylabel \\“Number of latency samples\\“ \\
\nset output \\“plot.png\\“ \\
\nplot “ >plotcmd<\/p>\n
\nfor i in `seq 1 `
\ndo
\nif test 1 != 1
\nthen
\necho -n „, “ >>plotcmd
\nfi
\ncpuno=`expr 1 – 1`
\nif test -lt 10
\nthen
\ntitle=“ CPU“
\nelse
\ntitle=“CPU“
\nfi
\necho -n „\\“histogram1\\“ using 1:2 title \\“\\“ with
\nhisteps“ >>plotcmd
\ndone<\/p>\n
\ngnuplot -persist <plotcmd<\/p>\nAnalyse eines Systems mit unbefriedigenden Echtzeiteigenschaften<\/h2>\n
Weitere Testmethoden bei Vorliegen unbefriedigender Echtzeiteigenschaften<\/h2>\n
Beispiel f\u00fcr die Verwendung des Testprogramm\u00a0cyclictest\u00a0<\/em>mit\u00a0breaktrace<\/em><\/h2>\n
\n<\/span><\/p>\n
\nT: 1 P:90 I:600 C:11940 Min:29 Act: 111 Avg:118 Max: 291
\nT: 2 P:90 I:600 C:11928 Min:31 Act: 189 Avg:141 Max: 295
\nT: 3 P:90 I:600 C:11911 Min:28 Act:3120 Avg:296 Max:3120
\n# Thread Ids: 18116 18118 18124 18127
\n# Break thread: 18127
\n# Break value: 3120<\/p>\nBeispiel f\u00fcr die Verwendung des internen Latenz-Histogramme des Kernels<\/h2>\n
\ninit\/Kconfig | 1 +
\n1 file changed, 1 insertion(+)
\nIndex: linux-4.9.47-rt37\/init\/Kconfig
\n==============================================================
\n— linux-4.9.47-rt37.orig\/init\/Kconfig
\n+++ linux-4.9.47-rt37\/init\/Kconfig
\n@@ -1946,6 +1946,7 @@ config SLABINFO
\n<\/strong>bool
\ndepends on PROC_FS
\ndepends on SLAB || SLUB_DEBUG
\n+ depends on !PREEMPT_RT_FULL
\n<\/strong>default y
\nconfig RT_MUTEXES<\/p>\nAutor<\/h2>\n
\nOpen Source – unsere Trainings & Coachings<\/h2>\n
\nOpen Source – Fachwissen<\/h2>\n