fix ae oe ue in tex files

Signed-off-by: Manuel Traut <manut@linutronix.de>

2 files changed, 116 insertions, 116 deletions

diff --git a/realtime/rt-basics/handout_rt-basics_de.tex b/realtime/rt-basics/handout_rt-basics_de.tex
index dd775b6..8580797 100644
--- a/realtime/rt-basics/handout_rt-basics_de.tex
+++ b/realtime/rt-basics/handout_rt-basics_de.tex
@@ -5,13 +5,13 @@
 \subsubsection{Grundlagen}
 
 \paragraph{Was ist Echtzeit?}
-Vor der Betrachtung verschiedener Ansätze, Linux echtzeitfähig zu machen, ist es
-notwendig, einige grundlegende Begrifflichkeiten zur erläutern:
+Vor der Betrachtung verschiedener Ans\"atze, Linux echtzeitf\"ahig zu machen, ist es
+notwendig, einige grundlegende Begrifflichkeiten zur erl\"autern:
 \begin{itemize}
 \item Echtzeit:
 Zur Definition eines Echtzeitsystems kann man folgende Aussagen Treffen: Auf
-einem Echtzeitsystem hängt die Korrektheit einer Berechnung nicht nur von ihrer
-logischen Korrektheit, sondern auch von der Ausführung zum korrekten Zeitpunkt
+einem Echtzeitsystem h\"angt die Korrektheit einer Berechnung nicht nur von ihrer
+logischen Korrektheit, sondern auch von der Ausf\"uhrung zum korrekten Zeitpunkt
 ab. Das Nichteinhalten eines bestimmten Zeitrahmens resultiert in einem Fehler.
 \item Latenzzeit: Unter Latenzzeit versteht man den Zeitraum zwischen dem
 Auftreten eines Events und der Reaktion auf dieses Event.
@@ -19,47 +19,47 @@ Auftreten eines Events und der Reaktion auf dieses Event.
 \end{itemize}
 
 \paragraph{Anwendungsbereiche}
-Die wohl gängigsten Anwendungsbereiche für Echtzeitsysteme sind die
+Die wohl g\"angigsten Anwendungsbereiche f\"ur Echtzeitsysteme sind die
 Steuerungs- und Automatisierungstechnik, Multimediasysteme und die Luft- und
 Raumfahrttechnik. Ein weiteres interessantes Einsatzgebiet stellt die 
 Finanzdienstleistung dar. Hier geht es insbesondere um die zeitgenaue,
-zuverlässige Abwicklung von Finanztransaktionen über hochverteilte Systeme.
+zuverl\"assige Abwicklung von Finanztransaktionen \"uber hochverteilte Systeme.
 
 \paragraph{Anforderungen an ein Echtzeitsystem}
-Ein Echtzeitsystem muß in der Lage sein, in einem garantierten Zeitrahmen auf
-ein Ereignis zu reagieren. Es muß also möglich sein, in möglichst kurzer Zeit
+Ein Echtzeitsystem mu\ss  in der Lage sein, in einem garantierten Zeitrahmen auf
+ein Ereignis zu reagieren. Es mu\ss  also m\"oglich sein, in m\"oglichst kurzer Zeit
 von einer niederprioren Task auf eine hochpriore Task umzuschalten, falls diese
-Rechenzeit benötigt. Das System muß also möglichst ''feingranular''
+Rechenzeit ben\"otigt. Das System mu\ss  also m\"oglichst ''feingranular''
 unterbrechbar sein.
 Doch allein die Unterbrechbarkeit kann kein deterministisches Zeitverhalten
 garantieren. So kann eine niederpriore Task Resourcen blockieren, die von einer
-hochprioren Task benötigt werden. Wird die niederpriore Task nun unterbrochen,
-kommt es zur ''Prioritätsinversion / priority inversion'', da die hochpriore Task
+hochprioren Task ben\"otigt werden. Wird die niederpriore Task nun unterbrochen,
+kommt es zur ''Priorit\"atsinversion / priority inversion'', da die hochpriore Task
 auf die Freigabe der Resource wartet, diese aber erst wieder dann freigegeben
 wird, wenn die niederpriore Task wieder Rechenzeit bekommt.
-Gelöst werden kann dieses Problem durch ''prioriy inheritance'' und ''priority ceiling''.
+Gel\"ost werden kann dieses Problem durch ''prioriy inheritance'' und ''priority ceiling''.
 \begin{itemize}
-\item Prioritätsvererbung / priority inheritance: Hier wird die Priorität der
-niederprioren Task angehoben, um zu erreichen, daß die blockierte Resource
+\item Priorit\"atsvererbung / priority inheritance: Hier wird die Priorit\"at der
+niederprioren Task angehoben, um zu erreichen, da\ss  die blockierte Resource
 freigegeben werden kann.
-\item Prioritätsgrenzen / priority ceiling: Hier wird für jede Resource eine
-Prioritätsgrenze festgelegt. Jede Task, die die Resource belegt, wird auf die
-Prioritätsgrenze der Resource angehoben.
+\item Priorit\"atsgrenzen / priority ceiling: Hier wird f\"ur jede Resource eine
+Priorit\"atsgrenze festgelegt. Jede Task, die die Resource belegt, wird auf die
+Priorit\"atsgrenze der Resource angehoben.
 \end{itemize}
 
 \subsubsection{Realtime Linux Varianten}
 \paragraph{Historisches zu Echtzeitlinux}
-Im Gegensatz zu traditionellen Echtzeitsystem wurde Linux ursprünglich nicht als
+Im Gegensatz zu traditionellen Echtzeitsystem wurde Linux urspr\"unglich nicht als
 solches designt. Als General Purpose Operating System wurde Linux auf Fairness
-und Durchsatz optimiert. Linux echtzeitfähig zu machen, bedeutet also, ein
-Standardbetriebssystem um Echtzeitfunktionen bzw. entsprechende Sonderfälle zu
-erweitern. Mit dieser Tatsache lassen sich die zwei technischen Ansätze für
-Realtime Linux erklären.
+und Durchsatz optimiert. Linux echtzeitf\"ahig zu machen, bedeutet also, ein
+Standardbetriebssystem um Echtzeitfunktionen bzw. entsprechende Sonderf\"alle zu
+erweitern. Mit dieser Tatsache lassen sich die zwei technischen Ans\"atze f\"ur
+Realtime Linux erkl\"aren.
 \begin{itemize}
-\item Dual Kernel Ansatz: Hier koexistieren ein Echtzeitkernel, der für alle
-zeitkritischen Dinge zuständig ist, und ein Standard Linux Kernel. Dieser Ansatz
-setzt voraus, daß alle externen Events zuerst vom Echtzeitkernel bearbeitet
-werden, bevor Sie an den Linux Kernel weitergereicht werden können. Die
+\item Dual Kernel Ansatz: Hier koexistieren ein Echtzeitkernel, der f\"ur alle
+zeitkritischen Dinge zust\"andig ist, und ein Standard Linux Kernel. Dieser Ansatz
+setzt voraus, da\ss  alle externen Events zuerst vom Echtzeitkernel bearbeitet
+werden, bevor Sie an den Linux Kernel weitergereicht werden k\"onnen. Die
 bekanntesten Vertreter dieser Technik sind RTAI und Xenomai.
 \item In-Kernel Ansatz: Diese Methode macht Linux an sich zu einem
 Echtzeitsystem. Dieser Ansatz wird mit dem Realtime Preemption Patch verfolgt
@@ -69,11 +69,11 @@ Hauptzweig von Linux abgenickt wurde.
 
 \paragraph{RTAI}
 Das Realtime Application Interface (RTAI) ist eine Entwicklung der Technischen
-Universität Mailand und entstand unter der Schirmherrschaft von Professor Paolo
-Mantegazza. Oberstes Designziel von RTAI ist und war es, die kleinstmöglichen
+Universit\"at Mailand und entstand unter der Schirmherrschaft von Professor Paolo
+Mantegazza. Oberstes Designziel von RTAI ist und war es, die kleinstm\"oglichen
 Latenzzeiten auf einer gegebenen Hardwareplattform zu erzielen. Dieses
-Designziel bedingt diverse Einschränkungen für RTAI Applikationen. Weiterhin
-wird nur eine recht kleine Anzahl an Zielplattormen unterstützt (derzeit x86,
+Designziel bedingt diverse Einschr\"ankungen f\"ur RTAI Applikationen. Weiterhin
+wird nur eine recht kleine Anzahl an Zielplattormen unterst\"utzt (derzeit x86,
 x86\_64 und diverse ARM Plattformen).
 \begin{figure}[h]
 \centering
@@ -85,11 +85,11 @@ RTAI ist ein typischer Vertreter des Dual Kernel Ansatzes. Abbildung
 \ref{img:rtai} zeigt die Funktionsweise von RTAI.
 
 \paragraph{Xenomai}
-Das Xenomai Projekt wurde im Jahre 2001 gegründet. Im Gegensatz zu RTAI erlaubt
-Xenomai auch Echtzeit im Userpace (RTAI erlaubt dies nur sehr eingeschränkt).
+Das Xenomai Projekt wurde im Jahre 2001 gegr\"undet. Im Gegensatz zu RTAI erlaubt
+Xenomai auch Echtzeit im Userpace (RTAI erlaubt dies nur sehr eingeschr\"ankt).
 Die Besonderheit von Xenomai sind die sogenannten Skins, die es vereinfachen sollen,
 Applikationen von anderen Echtzeitsystemen nach Xenomai zu portieren.
-Xenomai Skins bilden die API dieser Systeme ab. Xenomai unterstützt derzeit
+Xenomai Skins bilden die API dieser Systeme ab. Xenomai unterst\"utzt derzeit
 folgende Architekturen: PowerPC32, PowerPC64, x86, x86\_64, Blackfin, ARM und
 ia64). Die zentralen Begriffe im Designkonzept von Xenomai stellen Xenomai
 Nucleus, die Interrupt Pipeline (IPIPE), Hardware Abstraction Layer (HAL) und
@@ -97,12 +97,12 @@ System Abstraction Layer (SAL) dar.
 IPIPE kann bildlich als virtueller Interruptkontroller betrachtet werden.
 Sie organisiert das System in verschiedenen Domains. Interrupts werden von
 IPIPE entgegengenommen und an die einzelnen Domains verteilt.
-Nucleus beeinhaltet die Xenomai Core Funktionalität. Dieser ist zuständig dafür,
-alle notwendigen Resourcen bereitzustellen, die Skins benötigen, um die Funktionalität
-von RTOSsen nachbilden zu können. Der Hardware Abstraction Layer beinhaltet
-den Plattform und CPU abhängigen Code. Alle darüberliegenden Layer (darunter auch Nucleus)
+Nucleus beeinhaltet die Xenomai Core Funktionalit\"at. Dieser ist zust\"andig daf\"ur,
+alle notwendigen Resourcen bereitzustellen, die Skins ben\"otigen, um die Funktionalit\"at
+von RTOSsen nachbilden zu k\"onnen. Der Hardware Abstraction Layer beinhaltet
+den Plattform und CPU abh\"angigen Code. Alle dar\"uberliegenden Layer (darunter auch Nucleus)
 bauen darauf auf. HAL ist kombiniert mit dem System Abstraction Layer. Dieser
-soll die darüberliegenden Layer, wie z.B. Nucleus, noch portierbarer machen.
+soll die dar\"uberliegenden Layer, wie z.B. Nucleus, noch portierbarer machen.
 Abbildung \ref{img:xenomai} zeigt das technische Zusammenspiel der Xenomai
 Komponenten. Abbildung \ref{img:ipipe} zeigt die Funktionsweise von IPIPE.
 \begin{figure}[h]
@@ -119,49 +119,49 @@ Komponenten. Abbildung \ref{img:ipipe} zeigt die Funktionsweise von IPIPE.
 \end{figure}
 
 \paragraph{Preempt RT}
-Der Realtime Preemption Patch entstand ursprünglich aus Arbeiten von Ingo Molnar
-und Thomas Gleixner. Beide sind bis zum heutigen Zeitpunkt die treibenden Kräfte
+Der Realtime Preemption Patch entstand urspr\"unglich aus Arbeiten von Ingo Molnar
+und Thomas Gleixner. Beide sind bis zum heutigen Zeitpunkt die treibenden Kr\"afte
 bei der Entwicklung von Preempt RT.
 Im Gegensatz zu RTAI und Xenomai macht Preempt RT den Linux Kernel an sich
-echtzeitfähig. Dies wird im Besonderen durch folgende Mechanismen erreicht:
+echtzeitf\"ahig. Dies wird im Besonderen durch folgende Mechanismen erreicht:
 \begin{itemize}
 \item Sleeping Spinlocks: Spinlocks werden durch RT Mutexe ersetzt. Raw
-Spinlocks ersetzen die Eigenschaft der ursprünglichen Spinlocks.
+Spinlocks ersetzen die Eigenschaft der urspr\"unglichen Spinlocks.
 \item Threaded Interrupt Handlers: Interrupt Handler laufen per Default nicht im
 harten Interruptkontext, sondern als Kernelthread.
 \end{itemize}
-Viele Mechanismen, die ursprünglich in Preempt RT entwickelt wurden, haben
+Viele Mechanismen, die urspr\"unglich in Preempt RT entwickelt wurden, haben
 bereits Ihren Weg in den Mainline Linuxzweig gefunden: High Resolution Timer
-(Hochauflösende Timer unabhängig vom Scheduler Tick), Priority Inheritance,
-generisches Interrupthandling für alle Architekturen und mit 2.6.30 nun auch die
+(Hochaufl\"osende Timer unabh\"angig vom Scheduler Tick), Priority Inheritance,
+generisches Interrupthandling f\"ur alle Architekturen und mit 2.6.30 nun auch die
 Threaded Interrupt Handler.
 Weiterhin hat sich die Linux Entwicklergemeinde bereits 2006 darauf geeinigt,
-daß Preempt RT in den Linux Kernel integriert wird. Weiterhin bietet der
-Realtime Preemption Patch den großen Vorteil, daß Echtzeitapplikationen als POSIX
+da\ss  Preempt RT in den Linux Kernel integriert wird. Weiterhin bietet der
+Realtime Preemption Patch den gro\ss en Vorteil, da\ss  Echtzeitapplikationen als POSIX
 Realtime Applikationen geschrieben werden. Es wird keine spezielle API
-verwendet. Preempt RT Unterstützt eine Vielzahl von Architekturen (PowerPc, x86,
+verwendet. Preempt RT Unterst\"utzt eine Vielzahl von Architekturen (PowerPc, x86,
 x86\_64, MIPS, ARM, ...).
 \begin{figure}[h]
 \centering
 \includegraphics[height=0.5\textwidth]{images/preempt_rt.png}
-\caption{Überblick Preempt RT}
+\caption{\"Uberblick Preempt RT}
 \label{img:preempt_rt}
 \end{figure}
 Wie Abbildung \ref{img:preempt_rt} zeigt, integriert Preempt RT die
-Echtzeitfunktionalität ''nahtlos'' in den Linux Kernel. Auch die Entwickler
-anderer Projekte haben die Vorzüge von Preempt RT bereits erkannt. Die Roadmap
-für Xenomai 3 sieht Preempt RT Support vor. Dies würde den Einsatz von Xenomai
-Skins auf Preempt RT Kerneln ermgöglichen.
+Echtzeitfunktionalit\"at ''nahtlos'' in den Linux Kernel. Auch die Entwickler
+anderer Projekte haben die Vorz\"uge von Preempt RT bereits erkannt. Die Roadmap
+f\"ur Xenomai 3 sieht Preempt RT Support vor. Dies w\"urde den Einsatz von Xenomai
+Skins auf Preempt RT Kerneln ermg\"oglichen.
 
 \subsubsection{Kontrollfragen}
 
 \begin{enumerate}
 \item Was sind die wichtigsten Anforderungen an ein Echtzeitsystem?
-\item Welche beiden Ansätze gibt es, um Linux echtzeitfähig zu machen?
-\item Was sind die bekanntesten Vertreter für Echtzeitlinux und welche der oben
-beschriebenen Ansätze verfolgen Sie?
-\item Wird für das Schreiben einer Echtzeitapplikation mit Preempt RT eine
-spezielle API benötigt?
+\item Welche beiden Ans\"atze gibt es, um Linux echtzeitf\"ahig zu machen?
+\item Was sind die bekanntesten Vertreter f\"ur Echtzeitlinux und welche der oben
+beschriebenen Ans\"atze verfolgen Sie?
+\item Wird f\"ur das Schreiben einer Echtzeitapplikation mit Preempt RT eine
+spezielle API ben\"otigt?
 \end{enumerate}
 
 \input{tailhandout}
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