RT speciality fixes

2 files changed, 25 insertions, 20 deletions

diff --git a/realtime/rt-specialties/handout_rt-specialties_de.tex b/realtime/rt-specialties/handout_rt-specialties_de.tex
index 372aa25..33dc9b6 100644
--- a/realtime/rt-specialties/handout_rt-specialties_de.tex
+++ b/realtime/rt-specialties/handout_rt-specialties_de.tex
@@ -89,7 +89,7 @@ Die RT Tests sind eine Sammlung von Programmen, zur Validierung der
 Eigenschaften von Echtzeitsystemen. Die RT Tests umfassen folgende Tools:
 \begin{itemize}
 \item cyclictest: High Resolution Timer Testsoftware.
-\item hwlatdetect: Python Script, zur Steuerung des Kernelmoduls zur Erkennung
+\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 signaltest: Benchmark, bei dem Signale zwischen Tasks ausgetauscht werden.
@@ -108,10 +108,10 @@ make
 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 Interval gemessen und hierfür die Maximale und Durchschnittliche
+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 Timerinterval:
+Timers und das gewünschte Timerintervall:
 \begin{lstlisting}
 # 4 Timertasks (2000 , 2500, 3000, 3500us)
 # -i options tells us the interval of the first task
@@ -130,7 +130,7 @@ T: 3 ( 2124) P:77 I:3500 C:  723 Min: 67 Act: 95 Avg: 96 Max: 177
 \end{lstlisting}
 \subsection*{Lastszenarien}
 Um eine Aussage über das Echtzeitverhaltens treffen zu können, interessiert in
-der Hauptsache das Verhalten in Worst-Case Szenarien (hohe CPU Laste, hohe
+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.
 Es erzeugt eine bestimme Anzahl an Prozessgruppen von Clients und Servern, die
@@ -154,9 +154,15 @@ 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. Dieser Wert 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:
+Echtzeittasks für 50ms suspendiert.
+Da Interrupts unter Preempt RT als Kernelthread mit Echtzeitprioriät 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:
 \begin{lstlisting}
 echo -1 > /proc/sys/kernel/sched_rt_runtime_us
 \end{lstlisting}
@@ -225,13 +231,13 @@ Die oben aufgelistete Applikation zeigt sehr schön, was notwendig ist, um eine
 Applikation mit deterministischem Zeitverhalten zu erzeugen:
 \begin{itemize}
 \item RT Scheduling Policy und Priorität festlegen
-\item Speicher locken, um zu vermeiden, um undeterministisches Zeitverhalten
-durch Pagefaults auszuschliessen.
-\item ''Stack Pre-Faulting'', um zu zu vermeiden, daß Stackfaults
+\item Speicher locken, um undeterministisches Zeitverhalten durch
+Pagefaults auszuschliessen.
+\item ''Stack Pre-Faulting'', um zu vermeiden, daß Stackfaults
 undeterministisches Zeitverhalten verursachen
 \end{itemize}
-Eine Ausgezeichnete Einführung zum Erstellen von Echtzeitapplikation und zur
-Verwendung von Preempt RT, findet sich unter:\newline
+Eine Ausgezeichnete Einführung zum Erstellen von Echtzeitapplikationen und zur
+Verwendung von Preempt RT findet sich unter:\newline
 http://rt.wiki.kernel.org
 \subsection*{Tracing / Latenzen aufspüren}
 \subsubsection*{FTrace}
@@ -239,18 +245,17 @@ Ein hervorragendes Werkzeug, um kernelseitige Codepfade aufzuspüren, die lange
 Latenzzeiten verursachen, ist Ftrace. Ftrace wird über 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 verwenden. Die Option -f schällt Cyclictests Ftrace
+Optionen, um FTrace zu steuern. Die Option -f schällt Cyclictests Ftrace
 Support an, -b <max\_latency> veranlaßt Cyclictest, bei Überschreiten einer
 maximalen Latenzzeit, abzubrechen und einen Trace zu triggern.
 \subsubsection*{Kerneloptionen für FTrace}
-Um FTrace verwenden zu können, müssen beim Konfigurieren des Kernel einige
+Um FTrace verwenden zu können, müssen beim Konfigurieren des Kernels einige
 unter dem Menupunkt ''Kernel hacking-->Tracers'' einige Optionen aktiviert werden:
 \begin{itemize}
 \item Kernel Function Tracer
-\item Optional: Beliebige Optionen, die mit Trace beginnen (der zu verwendende
+\item Beliebige Optionen, die mit Trace beginnen (der zu verwendende
 Tracetyp kann cyclictest über die Commandline mitgegeben werden, siehe
-cyclictest -h. Default ist der
-Event Tracer)
+cyclictest -h. Default ist der Event Tracer)
 \end{itemize}
 \subsubsection*{Beispiel eines Traces}
 Das Erstellen eines Traces mit cyclictest läßt sich am Besten mit einem Beispiel
@@ -293,7 +298,7 @@ IRQ-129-772   [000] 4154503386.851234: timer_interrupt<-ret_from
 mindestens gesetzt sein?
 \item Wozu dient das Tool cyclictest?
 \item Welchen bekannten ''Pitfall'' gibt es bzgl. hoher Latencies mit Floodping
-als Lastszenario? Wie kann dieser behoben werden?
+als Lastszenario? Wie kann dieser umgangen werden?
 \item Welche 3 Schritte sind notwendig, um das deterministische Zeitverhalten
 einer Applikation zu garantieren?
 \end{itemize}
diff --git a/realtime/rt-specialties/pres_rt-specialties_de.tex b/realtime/rt-specialties/pres_rt-specialties_de.tex
index e7e3d1d..046521d 100644
--- a/realtime/rt-specialties/pres_rt-specialties_de.tex
+++ b/realtime/rt-specialties/pres_rt-specialties_de.tex
@@ -107,14 +107,14 @@ RT Tests:
 \item Setzt beliebige Anzahl von Realtime Tasks mit unterschiedlicher Priorität
 und unterschiedlichen Intervallen auf
 \item Viele Debuggingmöglichkeiten
-\item Sehr Aussagekräftig, um echtzeitverhalten auf einer bestimmten Plattform
+\item Sehr Aussagekräftig, um Echtzeitverhalten auf einer bestimmten Plattform
 zu beurteilen.
 \end{itemize}
 \end{frame}
 
 \begin{frame}
 \frametitle{Lastszenarien}
-Geeignete Lastszenarien, um Worst-Case Situationen nachstellen /provozieren zu
+Geeignete Lastszenarien, um Worst-Case Situationen nachstellen / provozieren zu
 können:
 \begin{itemize}
 \item CPU Last: ''hackbench'', ursprünglich als Scheduler Benchmark geschrieben.