diff options
Diffstat (limited to 'realtime/rt-specialties/handout_rt-specialties_de.tex')
| -rw-r--r-- | realtime/rt-specialties/handout_rt-specialties_de.tex | 116 |
1 files changed, 58 insertions, 58 deletions
diff --git a/realtime/rt-specialties/handout_rt-specialties_de.tex b/realtime/rt-specialties/handout_rt-specialties_de.tex index 54771ca..2f19a2b 100644 --- a/realtime/rt-specialties/handout_rt-specialties_de.tex +++ b/realtime/rt-specialties/handout_rt-specialties_de.tex @@ -6,7 +6,7 @@ Preempt RT wird als Patch gegen den Mainline Linux Kernel gepflegt. Unter:\newline http://www.kernel.org/pub/linux/kernel/projects/rt sind die aktuellsten Patche -für Preempt RT zu finden. Im Unterverzeichnis older/ sind ältere Patche +f\"ur Preempt RT zu finden. Im Unterverzeichnis older/ sind \"altere Patche archiviert. Das Vorbereiten eines Kerneltrees mit Preempt RT ist denkbar einfach: \begin{lstlisting} @@ -34,8 +34,8 @@ cd linux-2.6.29.5-rt21 ketchup -f --no-gpg 2.6.29.5-rt21 \end{lstlisting} -\paragraph{Konfigurieren und Übersetzen eines Preempt RT Kernels} -Die Konfiguration und das Übersetzen machen keinen Unterschied zu Linux ohne +\paragraph{Konfigurieren und \"Ubersetzen eines Preempt RT Kernels} +Die Konfiguration und das \"Ubersetzen machen keinen Unterschied zu Linux ohne Preempt RT Patch: \begin{lstlisting} # external build directory @@ -44,7 +44,7 @@ mkdir ../build cp /boot/config-x-x-x ../build/.config make O=../build oldconfig \end{lstlisting} -Für ein Echtzeitsystem müssen verschiedene Kerneloptionen aktiviert werden: +F\"ur ein Echtzeitsystem m\"ussen verschiedene Kerneloptionen aktiviert werden: \begin{lstlisting} make O=../build menuconfig \end{lstlisting} @@ -54,7 +54,7 @@ bzw. ''Processor type and features''. \centering \includegraphics[height=0.5\textwidth]{images/menu_rt_001.png} \end{figure} -Dort müssen folgende Optionen aktiviert werden: +Dort m\"ussen folgende Optionen aktiviert werden: \begin{itemize} \item High Resolution Timer Support \item Preemption Mode (Complete Preemption (Real-Time)) @@ -71,7 +71,7 @@ Dort müssen folgende Optionen aktiviert werden: \centering \includegraphics[height=0.5\textwidth]{images/menu_rt_004.png} \end{figure} -Das Übersetzen des Kernels erfolgt nun wie üblich mit +Das \"Ubersetzen des Kernels erfolgt nun wie \"ublich mit \begin{lstlisting} make O=../build make O=../build modules @@ -87,7 +87,7 @@ Eigenschaften von Echtzeitsystemen. Die RT Tests umfassen folgende Tools: \item cyclictest: High Resolution Timer Testsoftware. \item hwlatdetect: Python Script zur Steuerung des Kernelmoduls zur Erkennung von System Management Interrupts (hwlat\_detector). -\item pi\_stress: Stresstest für Mutexe mit Priority Inheritance Attribut +\item pi\_stress: Stresstest f\"ur Mutexe mit Priority Inheritance Attribut \item signaltest: Benchmark, bei dem Signale zwischen Tasks ausgetauscht werden. \end{itemize} Die Sourcen der RT Tests werden in einem GIT Tree verwaltet. @@ -103,11 +103,11 @@ make \subparagraph{Cyclictest} Cyclictest ist die wohl meistgenutzte Testsoftware auf Preempt RT Systemen. Mit Cyclictest kann eine bestimmte Anzahl von Timertasks mit einem definierten -Interval aufgesetzt werden. Für diese Tasks wird kontinuierlich die Abweichung -zum gewünschten Intervall gemessen und hierfür die Maximale und Durchschnittliche -Abweichung aufgezeichnet. Die wichtigsten Parameter für Cyclictest sind die -Anzahl und die Priorität der gewünschten Timertasks, die Art des zu verwendenden -Timers und das gewünschte Timerintervall: +Interval aufgesetzt werden. F\"ur diese Tasks wird kontinuierlich die Abweichung +zum gew\"unschten Intervall gemessen und hierf\"ur die Maximale und Durchschnittliche +Abweichung aufgezeichnet. Die wichtigsten Parameter f\"ur Cyclictest sind die +Anzahl und die Priorit\"at der gew\"unschten Timertasks, die Art des zu verwendenden +Timers und das gew\"unschte Timerintervall: \begin{lstlisting} # 4 Timertasks (2000 , 2500, 3000, 3500us) # -i options tells us the interval of the first task @@ -125,53 +125,53 @@ T: 2 ( 2123) P:78 I:3000 C: 841 Min: 54 Act: 76 Avg: 82 Max: 136 T: 3 ( 2124) P:77 I:3500 C: 723 Min: 67 Act: 95 Avg: 96 Max: 177 \end{lstlisting} \paragraph{Lastszenarien} -Um eine Aussage über das Echtzeitverhaltens treffen zu können, interessiert in +Um eine Aussage \"uber das Echtzeitverhaltens treffen zu k\"onnen, interessiert in der Hauptsache das Verhalten in Worst-Case Szenarien (hohe CPU Last, hohe Interruptlast). Ein ausgezeichnetes Werkzeug, um CPU Last zu erzeugen, ist -''hackbench''. Hackbench wurde ursprünglich als Schedulerbenchmark entwickelt. +''hackbench''. Hackbench wurde urspr\"unglich als Schedulerbenchmark entwickelt. Es erzeugt eine bestimme Anzahl an Prozessgruppen von Clients und Servern, die -über Sockets miteinander kommunizieren:\newline +\"uber Sockets miteinander kommunizieren:\newline http://people.redhat.com/mingo/cfs-scheduler/tools/hackbench.c -Interruptlast, läßt sich hervorragend mit einem Floodping von einem entfernten -Rechner erzeugen. Ein Floodping schickt eine große Anzahl von ICMP Paketen in +Interruptlast, l\"a\ss t sich hervorragend mit einem Floodping von einem entfernten +Rechner erzeugen. Ein Floodping schickt eine gro\ss e Anzahl von ICMP Paketen in kurzer Zeit. Dies erzeugt eine hohe Anzahl von Netzwerkinterrupts. Um Floodpings -zu generieren muß das Programm ping mit Rootrechten und mit der Option -f -ausgeführt werden. +zu generieren mu\ss das Programm ping mit Rootrechten und mit der Option -f +ausgef\"uhrt werden. \subparagraph{Pitfall} -Ein sehr häufig gemeldetes Phänomen bei Testläufen von Cyclictest mit einem -Floodping als Lastszenario, sind extrem große Ausreißer in der Größenordnung von -50ms. Dies ist auf ein ''Feature'' aktueller Preempt RT Kernel zurückzuführen. +Ein sehr h\"aufig gemeldetes Ph\"anomen bei Testl\"aufen von Cyclictest mit einem +Floodping als Lastszenario, sind extrem gro\ss e Ausrei\ss er in der Gr\"o\ss enordnung von +50ms. Dies ist auf ein ''Feature'' aktueller Preempt RT Kernel zur\"uckzuf\"uhren. Da Preempt RT auch auf vielen Desktops eingesetzt wird, auf denen Low Latency -Anwendungen betrieben werden (z.B. Multimedia Anwendungen), häuften sich -Fehlerberichte, die letztendlich nicht auf ein Kernelproblem zurückzuführen +Anwendungen betrieben werden (z.B. Multimedia Anwendungen), h\"auften sich +Fehlerberichte, die letztendlich nicht auf ein Kernelproblem zur\"uckzuf\"uhren waren, sondern auf eine Realtime Applikation, die den Rest des Systems -aushungerte. Daher wurde eine Option eingeführt, die die Laufzeit von Realtime -Tasks beschränken kann. Überschreiten die Realtime Tasks dieses Zeitlimit, -werden diese für einen bestimmten Zeitraum nicht mehr geschedult. Die -Standardeinstellung liegt bei 950ms. Bei Überschreiten der 950ms werden die -Echtzeittasks für 50ms suspendiert. -Da Interrupts unter Preempt RT als Kernelthread mit Echtzeitprioriät laufen +aushungerte. Daher wurde eine Option eingef\"uhrt, die die Laufzeit von Realtime +Tasks beschr\"anken kann. \"Uberschreiten die Realtime Tasks dieses Zeitlimit, +werden diese f\"ur einen bestimmten Zeitraum nicht mehr geschedult. Die +Standardeinstellung liegt bei 950ms. Bei \"Uberschreiten der 950ms werden die +Echtzeittasks f\"ur 50ms suspendiert. +Da Interrupts unter Preempt RT als Kernelthread mit Echtzeitpriori\"at laufen und durch den Floodping eine hohe Anzahl an Netzwerkinterrupts -(einschliesslich der zugehörigen Softinterrupts) erzeugt wird, nehmen Realtime -Tasks im System einen Großteil der Resourcen ein. Somit kann es passieren, daß -dieses Zeitlimit überschritten wird. -Das Limit für die Rechenzeit kann durch Schreiben des gewünschten Wertes nach -/proc/sys/kernel/sched\_rt\_runtime\_us angepaßt werden. -Zum Deaktivieren dieser Funktion muß Folgendes getan werden: +(einschliesslich der zugeh\"origen Softinterrupts) erzeugt wird, nehmen Realtime +Tasks im System einen Gro\ss teil der Resourcen ein. Somit kann es passieren, da\ss +dieses Zeitlimit \"uberschritten wird. +Das Limit f\"ur die Rechenzeit kann durch Schreiben des gew\"unschten Wertes nach +/proc/sys/kernel/sched\_rt\_runtime\_us angepa\ss t werden. +Zum Deaktivieren dieser Funktion mu\ss Folgendes getan werden: \begin{lstlisting} echo -1 > /proc/sys/kernel/sched_rt_runtime_us \end{lstlisting} -\subsubsection{Erstellen einer Realtime Task für Preempt RT} -\paragraph{Schedulingklassen / Prioritäten} +\subsubsection{Erstellen einer Realtime Task f\"ur Preempt RT} +\paragraph{Schedulingklassen / Priorit\"aten} Eine Realtime Applikation auf Preempt RT ist eine POSIX Realtime Applikation. -POSIX sieht für Echtzeitapplikationen folgende Schedulingstrategien vor: +POSIX sieht f\"ur Echtzeitapplikationen folgende Schedulingstrategien vor: \begin{itemize} -\item SCHED\_FIFO: Scheduling mit statischen Prioriäten -\item SCHED\_RR: Round Robin mit Prioritäten +\item SCHED\_FIFO: Scheduling mit statischen Priori\"aten +\item SCHED\_RR: Round Robin mit Priorit\"aten \end{itemize} -Echtzeitpriorität bekommt eine Applikation nur dann, wenn dies explizit -gewünscht wird. Hierzu ist die Funktion sched\_setscheduler() vorgesehen. +Echtzeitpriorit\"at bekommt eine Applikation nur dann, wenn dies explizit +gew\"unscht wird. Hierzu ist die Funktion sched\_setscheduler() vorgesehen. \paragraph{Beispiel einer Echtzeitapplikation} Das folgende Beispiel zeigt eine einfache POSIX Realtimeapplikation: \begin{lstlisting} @@ -223,39 +223,39 @@ int main(int argc, char* argv[]) } } \end{lstlisting} -Die oben aufgelistete Applikation zeigt sehr schön, was notwendig ist, um eine +Die oben aufgelistete Applikation zeigt sehr sch\"on, was notwendig ist, um eine Applikation mit deterministischem Zeitverhalten zu erzeugen: \begin{itemize} -\item RT Scheduling Policy und Priorität festlegen +\item RT Scheduling Policy und Priorit\"at festlegen \item Speicher locken, um undeterministisches Zeitverhalten durch Pagefaults auszuschliessen. -\item ''Stack Pre-Faulting'', um zu vermeiden, daß Stackfaults +\item ''Stack Pre-Faulting'', um zu vermeiden, da\ss Stackfaults undeterministisches Zeitverhalten verursachen \end{itemize} -Eine Ausgezeichnete Einführung zum Erstellen von Echtzeitapplikationen und zur +Eine Ausgezeichnete Einf\"uhrung zum Erstellen von Echtzeitapplikationen und zur Verwendung von Preempt RT findet sich unter:\newline http://rt.wiki.kernel.org -\paragraph{Tracing / Latenzen aufspüren} +\paragraph{Tracing / Latenzen aufsp\"uren} \subparagraph{FTrace} -Ein hervorragendes Werkzeug, um kernelseitige Codepfade aufzuspüren, die lange -Latenzzeiten verursachen, ist Ftrace. Ftrace wird über DebugFS, einem virtuellen +Ein hervorragendes Werkzeug, um kernelseitige Codepfade aufzusp\"uren, die lange +Latenzzeiten verursachen, ist Ftrace. Ftrace wird \"uber DebugFS, einem virtuellen Dateisystem, gesteuert und platziert dort auch seine Ausgaben. Die einfachste Methode, FTrace zu verwenden ist Cyclictest. Cyclictest biete bereits einige -Optionen, um FTrace zu steuern. Die Option -f schällt Cyclictests Ftrace -Support an, -b <max\_latency> veranlaßt Cyclictest, bei Überschreiten einer +Optionen, um FTrace zu steuern. Die Option -f sch\"allt Cyclictests Ftrace +Support an, -b <max\_latency> veranla\ss t Cyclictest, bei \"Uberschreiten einer maximalen Latenzzeit, abzubrechen und einen Trace zu triggern. -\subparagraph{Kerneloptionen für FTrace} -Um FTrace verwenden zu können, müssen beim Konfigurieren des Kernels einige +\subparagraph{Kerneloptionen f\"ur FTrace} +Um FTrace verwenden zu k\"onnen, m\"ussen beim Konfigurieren des Kernels einige unter dem Menupunkt ''Kernel hacking-->Tracers'' einige Optionen aktiviert werden: \begin{itemize} \item Kernel Function Tracer \item Beliebige Optionen, die mit Trace beginnen (der zu verwendende -Tracetyp kann cyclictest über die Commandline mitgegeben werden, siehe +Tracetyp kann cyclictest \"uber die Commandline mitgegeben werden, siehe cyclictest -h. Default ist der Event Tracer) \end{itemize} \subparagraph{Beispiel eines Traces} -Das Erstellen eines Traces mit cyclictest läßt sich am Besten mit einem Beispiel -erläutern: +Das Erstellen eines Traces mit cyclictest l\"a\ss t sich am Besten mit einem Beispiel +erl\"autern: \begin{lstlisting} # mount DebugFS mkdir -p /mnt/debugfs @@ -290,7 +290,7 @@ IRQ-129-772 [000] 4154503386.851234: timer_interrupt<-ret_from \paragraph{Kontrollfragen} \begin{itemize} -\item Welche Optionen sollten beim Übersetzen eines Preempt RT Kernels +\item Welche Optionen sollten beim \"Ubersetzen eines Preempt RT Kernels mindestens gesetzt sein? \item Wozu dient das Tool cyclictest? \item Welchen bekannten ''Pitfall'' gibt es bzgl. hoher Latencies mit Floodping |