From 4927aaf655f3e250dc67267d10613647374f1795 Mon Sep 17 00:00:00 2001
From: Manuel Traut <manut@linutronix.de>
Date: Wed, 14 Mar 2012 06:20:14 +0100
Subject: fix ae oe ue in tex files

Signed-off-by: Manuel Traut <manut@linutronix.de>
---
 .../rt-specialties/handout_rt-specialties_de.tex   | 116 ++++++++++-----------
 1 file changed, 58 insertions(+), 58 deletions(-)

(limited to 'realtime/rt-specialties/handout_rt-specialties_de.tex')

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
-- 
cgit v1.2.3

