path: root/cap/datacom.tex

\section{Performancebewertung}
\label{sec:versuche}

\begin{tabular}[t]{r|l}
 One of the problems of taking things apart & \\ 
 and seeing how they work & \\
 \emph{supposing you're trying to find out how a cat works}& \\
 you take that cat apart to see how it works, & \\
 what you've got in your hands is a non-working cat. & \\
 The cat wasn't a sort of clunky mechanism & \\
 that was susceptible to our available tools of analysis. & \textsl{Douglas Adams,}\\
 & \textsl{Hitchhiker's Guide to the Galaxy} \\
\end{tabular}

\vspace{1cm}

\dots will man die Performance von Real-time Applikationen messen, ohne deren Real-timeverhalten dabei zu beeinflussen, ist man auch auf die richtige Art der Analyse angewiesen. Eine Messung per Software w\"urde das Echtzeitverhalten der Applikationen beeinflussen. Deshalb entschied ich mich, die Messungen in Hardware durchzuf\"uhren.

In diesem Kapitel werden Applikationen zur \"Ubertragung von Prozessabbildern und Logdateien vorgestellt. Der aktuelle Zustand des Speicherbereichs, welcher die digitalen Ein- und Ausg\"ange eines Systems abbildet, wird Prozessabbild genannt. Dabei wird die Latenz bei der \"Ubertragung des Prozessabbildes gemessen. Es wird erl\"autert wie die Latenz gemessen wurde. Au\ss erdem wird auf den Aufbau des verwendeten ACE/TAO Frameworks eingegangen.

In Anhang \ref{sec:systemkonfigurationen} ist die Hard- und Softwareumgebung beschrieben, in der die in diesem Kapitel beschriebenen Versuche durchgef\"uhrt wurden.

\subsection{Ende zu Ende Latenz messen}

Es wurde eine Testumgebung (siehe Abb. \ref{img:rtmess}) geschaffen, in der die Latenz bei der \"Ubertragung von Prozessabbildern gemessen werden kann. 

Die entwickelten Applikationen erm\"oglichen es, mit einem Oszilloskop die Latenzzeit zu bestimmen. Hierzu wurde eine Rechteckspannung an einem digita"len Eingang des embedded Systems, im Folgenden CPX (siehe  Anhang \ref{sec:cpx}) genannt, angelegt. Jede \"Anderung an einem digitalen Eingangsport wird \"uber das verteilte System auf den digitalen Ausgang einer anderen CPX \"ubertragen.

Ein Speicheroszilloskop\footnote{in meinem Fall ein Tektronix TDS 3034B \cite{tektronix}} zeichnet die generierte Rechteckspannung und das \"uber das verteilte System \"ubertragene Signal in einer CSV\footnote{Comma Separated Values \cite{csv}} Datei auf. 

\newpage

\lstinputlisting{./cap/ausschnitt.csv}

Im oben abgedruckten Ausschnitt aus einer aufgezeichneten CSV-Datei ist die Verz\"ogerung des \"ubertragenen Signals (3. Wert jeder Zeile) gegen\"uber dem Signal des Frequenzgenerators (2. Wert) am Polarit\"atswechsel zu erkennen. Der 1. Wert ist ein Zeitstempel. Zum Zeitpunkt $2.48*10^{-03}$ in Zeile 4 wechselt das vom Frequenzgenerator generierte Signal (2. Wert) die Polarit\"at. In Zeile 19 zum Zeitpunkt $2.78*10^{-03}$ wechselt das \"ubertragene Signal (3. Wert) die Polarit\"at. Daraus kann die Latenz der \"Ubertragung berechnet werden:
\begin{equation}
2,78*10^{-03} - 2,48*10^{-03} = 300*10^{-6} [sec]
\end{equation}
Da eine einzige Latenzzeit nichts \"uber die Qualit\"at des Echtzeitsystems aussagt, wurde ein Programm erstellt, welches die komplette CSV-Datei auswertet. Es werden alle Latenzen (ansteigende und abfallende Flanke) berechnet. Ein Histogramm \"uber die Latenzzeiten wird grafisch mit gnuplot \cite{gnuplot} ausgegeben. Der Mittelwert, sowie Modalwert mit Spannweite in best und worst case Richtung werden bestimmt. Das Programm ist in der Lage ein weiteres Signal zu analysieren. Grafisch werden dessen Latenzschwankungen mit einer anderen Farbe im selben Diagramm dargestellt. Siehe auch Anhang \ref{cap:latencsrc}.

Eine Programmierumgebung ist \"uber niedrig priorisierte Ethernetports mit den beiden CPXen verbunden. Sie dient zum Compilieren und \"Ubertragen der Quellen, sowie zum Erzeugen von Netzlast (siehe Kapitel \ref{cap:lastsim}).

\begin{figure}
\begin{center}
\includegraphics[width=\textwidth]{./img/versuch1.jpg}
\caption{Versuchsaufbau f\"ur Latenzmessungen}
\label{img:rtmess}
\end{center}
\hrule
\end{figure}

\subsection{Lastsimulationen}
\label{cap:lastsim}
Um die Echtzeiteigenschaften des Systems zu \"uberpr\"ufen, werden die embedded PCs w\"ahrend den Messungen belastet:

\begin{description}
\item[Harddisk: ] \emph{xdd -op read -targets 1 /dev/hda -reqsize 8000 -numregs 128 -verbose} simuliert auf dem Rechner, auf dem das Kommando ausgef\"uhrt wird, lesende Zugriffe auf /dev/hda. Details siehe \cite{xdd}.
\item[Netzwerk: ] Das Kommando \emph{ping -f -i 0 -l 100000 -s 1 -q IP} wird von einem Rechner, welcher direkt mit dem Ziel (IP) verbunden ist, als Benutzer \emph{root} ausgef\"uhrt. \textbf{-f -i 0}: keine Pause zwischen den Anfragen. \textbf{-l}: Anzahl Pakete die gesendet werden ohne eine Antwort zu erhalten. \textbf{-s}: Paketgr\"o\ss e in Bytes. \textbf{-q}: quiet keine Ausgaben. So wird eine sehr hohe Netzauslastung erzeugt. Dieser Befehl wird im Folgenden als flood ping bezeichnet.
\item[Prozessor: ] \emph{./cpuburnP5} \cite{cpuburn} lastet die CPU des Rechners, auf dem das Kommando ausgef\"uhrt wird, voll aus.
\end{description}

Haben diese Lastsimulationen eine Auswirkung auf das Echtzeitverhalten, so deutet dies auf Schwachstellen im gepatchten Linuxkernel hin.

Um die Echtzeitqualit\"aten des Schedulers eines verteilten Systems zu testen, m\"ussen parallel zu den hochpriorisierten Prozessabbild\"ubertragungen, nieder priorisierte, komplexe Berechnungen durchgef\"uhrt werden.

\subsection{RTCORBA Applikationen}

Zur Zeit ist ACE/TAO \cite{taohp} die einzige CORBA Distribution, welche die OMG RTCORBA Spezifikation \cite{rtcorbaspec} gr\"o\ss tenteils erf\"ullt und bereits produktiv eingesetzt wird. In Kapitel \ref{sec:ace} und \ref{sec:tao} wird das ACE/TAO Framework vorgestellt. An wichtigen Stellen wird die Implementation genauer beschrieben. Die  Kapitel \ref{sec:v1} bis \ref{sec:v5} beschreiben die durchgef\"uhrten Versuche und Messungen, zur Ermittlung der Performance einer Real-time CORBA Datenkommunikation mit ACE/TAO.

\subsubsection[ACE]{ACE - The ADAPTIVE Communication Environment}
\label{sec:ace}

ACE \cite{acehp} ist ein plattformunabh\"angiges, frei verf\"ugbares openSource Framework zur objektorientierten System- und Netzwerkprogrammierung.

\begin{figure}
\begin{center}
\includegraphics[width=\textwidth]{./img/ace.jpg}
\caption{Struktur des ACE Frameworks (Quelle: http://www.cs.wustl.edu/~schmidt/)}
\label{img:ace}
\end{center}
\hrule
\end{figure}

Auf Abbildung \ref{img:ace} ist zu erkennen, dass die Architektur des ACE Framework aus aufeinander gesetzten Schichten besteht. Ein OS Adaption Layer abstrahiert die  systemspezifischen Schnittstellen (zum Beispiel IPC oder den Zugriff auf das Dateisystem), der von ACE unterst\"utzten Betriebssysteme. Darauf aufgesetzt befindet sich beispielsweise das Reactor/Proactor Framework, welches f\"ur das Eventhandling verantwortlich ist. Das Acceptor und Connector Framework f\"ur ein- bzw. ausgehende Verbindungsaufbauten entkoppelt den Verbindungsaufbau von der Kommunikation. Ein CORBA Handler bietet eine Anbindung f\"ur CORBA Implementationen, wie zum Beispiel TAO (siehe Kapitel \ref{sec:tao}).

\subsubsection[TAO]{TAO - The ACE ORB}
\label{sec:tao}

TAO ist eine auf das Adaptive Communication Environment (ACE) aufsetzende  (siehe Kapitel \ref{sec:ace}, Abbildung \ref{img:ace}), frei verf\"ugbare, plattformunabh\"angige, openSource, C++ CORBA Distribution.

Dr. Douglas C. Schmidt, Entwicklungsleiter von ACE/TAO erkl\"art auf seiner Homepage \cite{schmidthp}, die wichtigsten Gr\"unde die Ihn zur Entwicklung von TAO bewegten:
\\
\begin{shadowenv}
\begin{itemize}
\item Erforschung der Grundlagen zur Implementierung eines Real-time CORBA ORBs (siehe Kapitel \ref{sec:rtcorba} f\"ur den Einsatz in verteilten (siehe Kapitel \ref{sec:distsys}), embedded (siehe \ref{sec:embedded}), Echtzeitsystemen (DRE - Distributed Real-time Systems).
\item Kombination von Echtzeit Ein- und Ausgabesystemarchitekturen mit einem optimierten ORB zur Implementierung einer Ende zu Ende CORBA Kommunikation mit Quality of Service (QoS) Anforderungen bez\"uglich Datendurchsatz, Latenzzeit, und Jitter \cite{ioqos}.
\item Anbieten einer qualitativ hochwertigen, frei verf\"ugbaren, openSource CORBA Middleware Plattform. TAO kann frei heruntergeladen, benutzt und weiterverbreitet werden.
\item Mitwirken bei der OMG \cite{omg} Real-time CORBA Spezifikation \cite{rtcorbaspec}
\item \dots
\end{itemize}
\end{shadowenv}

Im Nachfolgenden wird am Beispiel eines Servicerequests an einen Server (rechter Teil Abbildung \ref{rttao}) der Informationsfluss innerhalb von TAO beschrieben.

\begin{enumerate}
\piccaption{Architektur der TAO RT Komponenten (Quelle: \cite{schmidthp}\label{rttao})}
\parpic[r]{\includegraphics[width=0.4\textwidth]{./img/tao.jpg}}
\item I/O Subsystem erh\"alt \"uber das RT Netzwerk einen Request
\item Scheduler ermittelt Priorit\"at des Requests
\item Je nach Priorit\"at wird der Request auf eine der priorisierten Wartelisten gesetzt
\item Der ORB Core nimmt den Request aus der Warteliste und reicht ihn mit entsprechender Priorit\"at an den
\item Object Adapter weiter, welcher in konstanter Zeit das zugeh\"orige Objekt findet
\item dieses Objekt bearbeitet mit entsprechender Priorit\"at die Anfrage
\end{enumerate}

\vspace{2cm}

\paragraph{Scheduling}
\label{sec:taosched}

Die Qualit\"at und Art der Implementation des Schedulings von Tasks, definiert die Real-time Eigenschaften eines Multitaskingsystems.

In TAO wird f\"ur das Scheduling von Requests eine gepufferte Version des RMS (Rate Monotonic Scheduling, siehe \cite{tanenbaum} Chap. 7.4.3 page 472) eingesetzt. Hierzu werden Aufgaben in rates groups organisiert. 

Auf der I/O Ebene kann f\"ur jede rates group eine eigene Verbindung aufgebaut werden. Somit kann auf der I/O Ebene, ohne Betrachtung des Inhalts der einkommenden Daten bestimmt werden, mit welcher Priorit\"at diese verarbeitet werden.

Die so in einer rates group getakteten (zum Beispiel 20 Hz) Tasks werden im ORB via Fixed Priority Scheduling (siehe \cite{tanenbaum} Chap. 2.5.3 page 143, 144) einem mit entsprechend hoher Priorit\"at arbeitendem Threadpool \cite{threadpools} zugewiesen. Threadpools haben den Vorteil, dass sie eine fixe Anzahl von Threads inklusive Ressourcen zur Bearbeitung der zugewiesenen Aufgaben besitzen. W\"urden mehr Threads ben\"otigt, als der Threadpool zur Verf\"ugung stellt, werden die Aufgaben sp\"ater abgearbeitet. Somit wird ein st\"andiges Freigeben und neu Lokalisieren von Ressourcen verhindert. Anhand der Gr\"o\ss e des Threadpools kann die Performance optimiert werden.

\subparagraph[RT\_ Info]{RT\_ Info Struktur}
\label{sec:rtinfo}
Um das Scheduling zu optimieren m\"ussen TAO Applikationen alle zur Benutzung vorgesehenen Resourcen bekannt geben. Diese Angaben beeinflussen die Kompilierung des Programms. In der RT\_ Info Struktur (siehe Tabelle \ref{tab:rtinfo}) werden die echtzeitrelevanten Informationen einer Task gespeichert.

Aus diesen Informationen berechnet der Real-time Scheduler, welche Operationen in einem Thread zusammengefasst werden und mit welcher Betriebssystempriorit\"at dieser Thread arbeiten mu\ss ,  damit die Echtzeitanforderungen erf\"ullt werden k\"onnen.

Der Programmierer kann \"uber das \emph{RTCORBA::Current} Interface einem Objekt eine Priorit\"at zuweisen. Diese Zuweisung beeinflusst nicht nur die RT\_ Info Struktur des entsprechenden Objekts, sondern auch die RT\_ Info Strukturen der Objekte, von denen dieses Objekt abh\"angig ist (dependencies\_  Feld). Details siehe \cite{taoscheduling}
\newpage
\begin{longtable}{|l|l|l|}
\hline
\textbf{Feldname} & \textbf{Einheit}& \textbf{Beschreibung}\\
\hline
\textbf{worstcase\_ execution\_ time\_ } & Time $C$ & obere Schranke f\"ur \\
& & harte Echtzeitanforderungen \\
\hline
\textbf{typical\_ execution\_ time\_ } & Time $C$ & Schranke f\"ur \\
& & weiche Echtzeitanforderungen \\
\hline
\textbf{cached\_ execution\_ time\_ } & Time $C$ & falls $!= 0$ wird zur Optimierung \\
& & nur einmal innerhalb der \\
& & angegebenen Zeit die \\
& & \emph{worstcase\_ execution\_ time\_ } \\
& & verwendet. \\
\hline
\textbf{period\_ } & Time $C$ & Zeit zwischen periodischen \\
& & Aufrufen (z.B. bei Iterationen) \\
\hline
\textbf{criticality\_ } & Enum: VERY\_ LOW\_  \dots & wird vom Scheduler ausgewertet \\
& VERY\_ HIGH\_ CRITICALITY & \\
\hline
\textbf{importance\_ } & Enum: VERY\_ LOW\_  \dots & wird vom Scheduler nur \\
& VERY\_ HIGH\_ IMPORTANCE & ausgewertet, falls zwei \\
& & Aufgaben gleich wichtig sind \\
\hline
\textbf{quantum\_ } & Time $C$ & nicht benutzt / f\"ur gerechtes \\
& & Scheduling von niedrigst \\
& & priorisierten Aufgaben \\
\hline
\textbf{threads\_ } & Anzahl $n$ & intern von der Operation \\
& & benutzter Threads \\
\hline
\textbf{dependencies\_ } & Handles auf andere & von denen diese Operation direkt \\
& RT\_ Info Strukturen & abh\"angt. Aus dieser Information \\
& & werden intern Abh\"angigkeits- \\
& & graphen erstellt. Jeder Graph \\
& & wird in einem Thread \\
& & ausgef\"uhrt \\
\hline
\textbf{priority\_ } & Betriebssystempriorit\"at & wird von TAO aus den anderen \\
& & Informationen berechnet und \\
& & gesetzt \\
\hline
\textbf{subpriority\_ } & Unterpriorit\"at & zur Sortierung von RT\_ Infos mit \\
& & gleicher Priorit\"at (wird ebenfalls \\
& & von TAO berechnet und gesetzt) \\
\hline
\caption{RT\_ Info Struktur}
\label{tab:rtinfo}
\end{longtable}

\paragraph{RTPOA}
\label{sec:taopoa}
Der TAO RTPOA kann wahlweise nach der perfect Hashing oder der active Demultiplexing Methode arbeiten. Beide finden das zum IOR (Kapitel \ref{sec:ior}) zugeh\"orige Objekt in konstanter Zeit.

\begin{description}
\item[perfect Hashing] Eine perfect Hash Table bestimmt anhand des Hashwertes des IOR den zugeh\"origen Skeleton. Eine zweite Hash Table dient zur Bestimmung der zugeh\"origen Funktion. Hierzu wird das GNU Tool gperf verwendet. Perfect Hashing kann nur verwendet werden, wenn zum Zeitpunkt der Kompilierung bekannt ist, mit welchen Objektschl\"usseln und Funktionsnamen gearbeitet wird.
\item[active Demultiplexing] Sendet der Client die IOR im Request Header an den Server, so kann damit in einem Schritt der entsprechende Servant und die verkn\"upfte Operation bestimmt werden.
\end{description}

\subsubsection[V1 Prozessabbild \"ubertragen]{V1 Prozessabbild zwischen zwei embedded Systemen \"ubertragen}
\label{sec:v1}

Es wird der Status aller digitalen Eing\"ange von CPX2 auf den digitalen Ausg\"angen von CPX1 dargestellt. Hierbei soll die Latenz zwischen Zustands\"anderungen an den Eing\"angen von CPX2 und Zustands\"anderung der Ausg\"ange an CPX1 m\"oglichst gering und konstant sein.

\paragraph{Softwaredesign}

Abbildung \ref{img:rtmess}: CPX 2 agiert als RTCORBA Server. Als Servant wird ein Objekt zur Verf\"ugung gestellt, welches via Memory Mapping einen \"ubergebenen Wert direkt auf den digitalen Ausgang schreibt.

\"Anderungen an einem digitalen Eingang der CPX 1 werden mit einem RTCORBA Funktionsaufruf auf den digitalen Ausgang von CPX 2 geschrieben.

Das Sequenzdiagramm (Abb. \ref{img:sqV1}) zeigt die Kommunikation zwischen Receiver und Supplier. Das Holen der Objektreferenz vom NamingService, sowie CORBA interne Objekte wurden nicht dargestellt. Das Diagramm beinhaltet den Programmstart von Receiver und Supplier, sowie die \"Ubertragung einer Zustands\"anderung.

\begin{figure}
\begin{center}
\includegraphics[width=\textwidth]{./img/sequenzV1.jpg}
\caption{Sequenzdiagramm: V1 Prozessabbild \"ubertragen}
\label{img:sqV1}
\end{center}
\begin{center}
\includegraphics[width=0.85\textwidth]{./img/programmfluss.jpg}
\caption{Datenfluss : V1 Prozessabbild via TAO \"ubertragen}
\label{img:rtcom}
\end{center}
\end{figure}

\paragraph{Datenfluss}

In Abbildung \ref{img:rtcom} ist aufgezeigt, welche Komponenten die Daten passieren, um eine Port\"anderung via ACE/TAO von einer CPX auf die Andere zu \"ubertragen. Receiver und Supplier sind Komponenten, welche selber entwickelt wurden. Die restlichen Komponenten werden vom System zur Verf\"ugung gestellt, oder automatisch generiert.

\paragraph{Konfiguration}

Um Real-time in einem System sicher zu stellen, mu\ss\ sowohl das Betriebssystem, als auch die Applikation alle Real-time Kriterien (siehe Kapitel \ref{sec:Real-time}) erf\"ullen. Wichtig ist, dass die RTCORBA Daten in jeder Komponente (Abb. \ref{img:rtcom}) bevorzugt und nicht unterbrechbar bearbeitet werden. Hierzu mu\ss\ sowohl das Betriebssystem, wie auch das ACE/TAO Framework entsprechend konfiguriert werden.

\begin{description}
\item[Linux] Die RT\_ PREEMPT Erweiterung \cite{rt} cached IRQs und f\"uhrt diese innerhalb, je IRQ, eines Prozesses aus. Somit ist jeder Interrupthandler ein Prozess. Unter Linux besteht die M\"oglichkeit jedem Prozess eine Priorit\"at zuzuweisen. Die RT\_ PREEMPT Erweiterung dient unter anderem der Priorisierung von Interrupts. Es kann sichergestellt werden, dass eine Echtzeitanwendung nicht von einem Interrupt unterbrochen wird und f\"ur Echtzeitanwendungen ben\"otigte Interrupts bevorzugt abgearbeitet werden.

\item[ACE/TAO:] durch das Zuweisen von Policies k\"onnen Priorit\"aten von Threads und Objekten definiert werden. Es besteht die M\"oglichkeit die CORBA Priorit\"aten auf Betriebssystem- oder Netzwerkpriorit\"aten abzubilden, um einen Thread mit entsprechender Priorit\"at zu starten, oder die Netzwerkkommunikation zu priorisieren. In einer Konfigurationsdatei (svc.conf) k\"onnen zur Laufzeit die Art des Priority Mappings und des Schedulings ver\"andert werden.
\end{description}

\subparagraph{RT\_ PREEMPT Priorisierung}

Mit dem Tool rtnice\footnote{Download: http://www.tglx.de/projects/misc/rtnice/rtnice.tar.bz2} wurden die (negativen) Real-time Priorit\"aten wie folgt zugewiesen:

\begin{longtable}{|l||l|l|}
\hline
\textbf{Prozess} & \textbf{Priorit\"at}& \textbf{Kommentar}\\
\hline
\hline
Supplier & RT (-99) & RTCORBA Client \\
\hline
softirq-net-rx & -2 &  \\
\hline
softirq-net-tx & -40 & \\
\hline
IRQ 6 & -90 & Digitale Ein/Ausg\"ange\\
\hline
IRQ 14 & -2 & ide0\\
\hline
IRQ 17 & -90 & eth0 (f\"ur RT Kommunikation) \\
\hline
IRQ 18 & -2 & ethX (restliche Ethernetports) \\
\hline
\caption{Priorisierung CPX1 - Supplier - RTCORBA Client}
\label{tab:prioSup}
\end{longtable}
\newpage
\begin{longtable}{|l||l|l|}
\hline
\textbf{Prozess} & \textbf{Priorit\"at}& \textbf{Kommentar}\\
\hline
\hline
Receiver & RT (-99) & RTCORBA Server \\
\hline
softirq-net-rx & -40 &  \\
\hline
softirq-net-tx & -2 & Senden ist rel. unwichtig \\
\hline
IRQ 6 & -90 & Digitale Ein/Ausg\"ange\\
\hline
IRQ 14 & -2 & ide0\\
\hline
IRQ 17 & -90 & eth0 (f\"ur RT Kommunikation) \\
\hline
IRQ 18 & -2 & ethX (restliche Ethernetports) \\
\hline
\caption{Priorisierung CPX2 - Receiver - RTCORBA Server}
\label{tab:prioRec}
\end{longtable}

\begin{description}
\item[softirqs:] f\"uhren Interruptcode aus, welcher nicht zeitkritisch ist. Dies hat den Vorteil, dass die CPU nicht l\"anger als n\"otig von einer Interruptserviceroutine benutzt wird. Eine detailierte Beschreibung ist in \cite{love:kernel} ab Seite 142 zu finden.
\end{description}

\subparagraph{ACE/TAO Konfiguration}

\begin{description}
\item[Receiver: ] \emph{RTCORBA::priority\_ model\_ policy(RTCORBA::CLIENT\_ PROPAGATED, \\RTCORBA::maxPriority)} alle Anfragen werden mit h\"ochster Priorit\"at abgearbeitet
\item[Supplier: ] \emph{RTCORBA::private\_ connection\_ policy()} Verbindung wird nicht mit anderen Client-Server Verbindungen geteilt.
\item[svc.conf: ] keine
\end{description}
\newpage
\paragraph{Ergebnisse}

\begin{longtable}{||r|r|r||r|r|r|r|r|r|r|r|r|}
\hline
\multicolumn{3}{||r||}{\textbf{Supplier}} & \textit{CPU} & \textcolor{blue}{0} & 0 & 0 & 0 & \textcolor{blue}{1} & 1 & 1 & 1 \\
\cline{4-12}
\multicolumn{3}{||l||}{ }               & \textit{HD}   & \textcolor{blue}{0} & 0 & 1 & 1 & \textcolor{blue}{0} & 0 & 1 & 1 \\
\cline{4-12}
\multicolumn{3}{||l||}{\textbf{Receiver}} & \textit{NET} & \textcolor{blue}{0} & 1 & 0 & 1 & \textcolor{blue}{0} & 1 & 0 & 1 \\
\hline
\textit{CPU} & \textit{HD} & \textit{NET}  \\
\cline{1-3} \cline{5-12}
\textcolor{blue}{0}      & \textcolor{blue}{0}    & \textcolor{blue}{0}                              &         &\textcolor{blue}{595}&\textcolor{green}{630}&\textcolor{green}{590}&\textcolor{green}{763}&\textcolor{blue}{600}&\textcolor{green}{710}&\textcolor{green}{625}&\textcolor{green}{630}\\
\cline{1-3} \cline{5-12}
0      & 0    & 1                              &         &\textcolor{red}{945}&940&995&645&740&655&825&915\\
\cline{1-3} \cline{5-12}
0      & 1    & 0                              &         &\textcolor{red}{770}&2010&735&820&820&1175&860&925\\
\cline{1-3} \cline{5-12}
0      & 1    & 1                              &         &\textcolor{red}{1135}&1495&1115&\textbf{DR}&1120&1500&1240&\textbf{DR}\\
\cline{1-3} \cline{5-12}
\textcolor{blue}{1}      & \textcolor{blue}{0}    & \textcolor{blue}{0}                              &         &\textcolor{blue}{595}&675&645&725&\textcolor{blue}{600}&630&605&685\\
\cline{1-3} \cline{5-12}
1      & 0    & 1                              &         &\textcolor{red}{975}&758&1015&\textbf{DR}&660&985&1160&1500\\
\cline{1-3} \cline{5-12}
1      & 1    & 0                              &         &\textcolor{red}{745}&920&880&1035&1010&830&855&1005\\
\cline{1-3} \cline{5-12}
1      & 1    & 1                              &         &\textcolor{red}{1235}&1240&795&\textbf{DR}&1070&1110&\textbf{DR}&\textbf{DR}\\
\cline{1-3} \cline{5-12}
\caption{Latenzzeiten bei variierender Systembelastung}
\label{tab:sysLastMatrix}
\end{longtable}

Die Tabelle stellt die gemessenen Latenzzeiten (jeweils ansteigende + absteigende Flanke bei 400 Hz) bei variierender Systembelastung dar. \textbf{DR} bedeutet: $Duration_{Latenz} > Duration_{Periode}$, eine korrekte \"Ubertragung des Signals ist nicht mehr m\"oglich. Die \textcolor{blue}{blau} hervorgehobenen Werte zeigen, dass die CPU Auslastung die Echtzeit\"ubertragung nicht beeinflu\ss t. Die \textcolor{green}{gr\"unen} Werte zeigen, dass der Supplier auch unter Belastung korrekt arbeitet. Die \textcolor{red}{roten} Werte signalisieren, dass der Receiver unter HD und, oder NET Last noch nicht korrekt arbeitet.

Die nun beschriebenen Oszilloskop Screenshots sind Beispiele f\"ur die in Tabelle \ref{tab:sysLastMatrix} farblich hervorgehobenen Erkenntnisse:

\begin{figure}
  \begin{center}
  \begin{minipage}[t]{7.5 cm}
    \includegraphics[width=7.5cm]{./img/v1/0100.jpg}
    \caption{Receiver u. Supplier o. zus\"atzl. Systemlast}
    \label{img:sysLast0100}
  \end{minipage}
  \begin{minipage}[t]{1 cm}
  \end{minipage}
  \begin{minipage}[t]{7.5 cm}
     \includegraphics[width=7.5cm]{./img/v1/0136.jpg}
     \caption{Receiver o. zus\"atzl. Systemlast; Supplier mit CPU Last}
     \label{img:sysLast0136}
  \end{minipage}
  \end{center}
  \begin{center}
  \begin{minipage}[t]{7.5 cm}
	\includegraphics[width=\textwidth]{./img/v1/0108.jpg}
	\caption{Receiver o. zus\"atzl. Systemlast; Supplier m. CPU, Netz u. HD Last}
	\label{img:sysLast0108}
  \end{minipage}
  \begin{minipage}[t]{1 cm}
  \end{minipage}
  \begin{minipage}[t]{7.5 cm}
	\includegraphics[width=\textwidth]{./img/v1/0116.jpg}
	\caption{Receiver m. Netzlast; Supplier o. zus\"atzl. Last}
	\label{img:sysLast0116}
  \end{minipage}
  \end{center}
  \begin{center}
  \begin{minipage}[t]{7.5 cm}
	\includegraphics[width=\textwidth]{./img/v1/0213.jpg}
	\caption{Receiver u. Supplier m. CPU, Netz u. HD Last}
	\label{img:sysLast0213}
  \end{minipage}
  \begin{minipage}[t]{1 cm}
  \end{minipage}
  \begin{minipage}[t]{7.5 cm}
	\includegraphics[width=\textwidth]{./img/v1/0149.jpg}
	\caption{Receiver m. CPU u. HD Last; Supplier m. CPU, Netz u. HD Last}
	\label{img:sysLast0149}
  \end{minipage}
  \end{center}
\end{figure}

Abbildung \ref{img:sysLast0100}: Ohne zus\"atzlich produzierte Systemlast betr\"agt die Latenzzeit kontinuierlich 300 $\mu$s. Da alle an der Kommunikation beteiligten Prozesse sehr hoch priorisiert sind, d\"urfte in einem Echtzeitsystem eine Auslastung der Resourcen durch niedriger priorisierte Tasks die Latenzzeit nicht bedeutend ver\"andern. 

Abbildung \ref{img:sysLast0136}: Eine Auslastung der Supplier CPU beeinflusst die Latenzwerte nicht.

Abbildung \ref{img:sysLast0108}: Volle CPU Last, ein flood Ping und dauerhaftes Lesen von der Festplatte auf dem Supplier beeintr\"achtigt das Real-time Verhalten nicht.

Abbildung \ref{img:sysLast0116}: Ein flood ping auf den Receiver beeintr\"achtigt dessen Antwortverhalten. Vermutung: Priority Inversion bei der Abarbeitung von Netzwerkpaketen.

Abbildung \ref{img:sysLast0213}: Wird auf beiden Systemen Netz- CPU- und HD-Last erzeugt wird das Signal nicht mehr korrekt \"ubertragen. Eine fehlerfreie \"Ubertragung des Signals ist nicht mehr m\"oglich sobald $T_{Latenz} > \frac{T_{Periode}}{2}$.

Abbildung \ref{img:sysLast0149}: Ohne flood ping auf den Receiver kann das Signal korrekt \"ubertragen werden.

\subparagraph{Latenzschwankungen bei flood ping auf CPX2 (Receiver)}

Der Linux Kernel liest bei einem Interrupt der Netzwerkkartentreiber (IRQ 17/18)   die Ethernetdaten aus der Netzwerkkarte in den Arbeitsspeicher ein (siehe \emph{./linux/drivers/net/eepro100.c}). Die Auswertung dieser Ethernetdaten wird in einem softirq (siehe \emph{./linux/net/core/dev.c: net-rx-action()})  abgearbeitet. Ein Prozess bearbeitet die Ethernetdaten aller Ethernetdevices, deshalb ist es nicht m\"oglich durch IRQ-Prozesspriorisierung eine bevorzugte Abarbeitung der Daten der f\"ur die Echtzeitkommunikation genutzten Ethernetschnittstelle zu gew\"ahren.

\subparagraph{L\"osungsans\"atze}

Die L\"osungsans\"atze sind nach Implementierungsaufwand (gering \dots\ hoch) sortiert:

\begin{enumerate}
\item Priorit\"atenvergabe der IRQ Prozesse \"uberarbeiten
\item IRQ 18 w\"ahrend echtzeitkritischen Programmabl\"aufen deaktivieren
\item Abarbeitung des softirq-Codes innerhalb der Interruptserviceroutine des Netzwerkkartentreibers, softirqs niedrig priorisieren
\item Eigene softirqs f\"ur jedes Ethernetdevice
\end{enumerate}

\subparagraph{L\"osung}
\label{cap:reprio}

Durch die Neuzuordnung der IRQ-Priorit\"aten wurden die Latenzschwankungen nahezu eliminiert:

\begin{longtable}{|l||l|l|}
\hline
\textbf{Prozess} & \textbf{Priorit\"at}& \textbf{Kommentar}\\
\hline
\hline
Supplier & RT (-99) & RTCORBA Client \\
\hline
softirq-net-rx & -35 &  \\
\hline
softirq-net-tx & -40 & \\
\hline
IRQ 6 & -50 & Digitale Ein/Ausg\"ange\\
\hline
IRQ 14 & -2 & ide0\\
\hline
IRQ 17 & -80 & eth0 (f\"ur RT Kommunikation) \\
\hline
IRQ 18 & -2 & ethX (restliche Ethernetports) \\
\hline
\caption{Repriorisierung CPX1 - Supplier - RTCORBA Client}
\label{tab:rePrioSup}
\end{longtable}
\newpage
\begin{longtable}{|l||l|l|}
\hline
\textbf{Prozess} & \textbf{Priorit\"at}& \textbf{Kommentar}\\
\hline
\hline
Receiver & RT (-99) & RTCORBA Server \\
\hline
softirq-net-rx & -45 &  \\
\hline
softirq-net-tx & -20 & Senden ist rel. unwichtig \\
\hline
IRQ 6 & -50 & Digitale Ein/Ausg\"ange\\
\hline
IRQ 14 & -2 & ide0\\
\hline
IRQ 17 & -80 & eth0 (f\"ur RT Kommunikation) \\
\hline
IRQ 18 & -2 & ethX (restliche Ethernetports) \\
\hline
\caption{Repriorisierung CPX2 - Receiver - RTCORBA Server}
\label{tab:rePrioRec}
\end{longtable}

Beim Supplier wird die Priorit\"at des softirq-net-rx Prozesses erh\"oht, somit wird sichergestellt, dass die TCP-acknowledge Pakete vom Receiver rechtzeitig empfangen werden k\"onnen. Dies hat zur Folge, dass die Daten\"ubertragung nicht wegen eines fehlenden acknowledge Pakets eingefroren wird.

Der Receiver bekommt durch die Erh\"ohung der Priorit\"at von softirq-net-tx die Chance zeitgerecht die TCP-acknowledge Pakete zu versenden.

\begin{figure}
  \begin{center}
  \begin{minipage}[t]{7.7 cm}
	\includegraphics[width=\textwidth]{./img/v1/v1optOhneLast.jpg}
	\caption{Supplier u. Receiver o. Last}
	\label{img:optVerteilungOhneLast1}
  \end{minipage}
  \begin{minipage}[t]{7.7 cm}
	\includegraphics[width=\textwidth]{./img/v1/v1opt.jpg}
	\caption{Supplier u. Receiver m. xdd, flood ping u. cpuburnP5 belastet}
	\label{img:optVerteilung1}
  \end{minipage}
  \end{center}
 \hrule
\end{figure}

Abbildung \ref{img:optVerteilungOhneLast1} und \ref{img:optVerteilung1} zeigen, dass die Latenzzeiten nicht mehr gravierend mit der Systemauslastung korreliert sind. Durch die Repriorisierung der Interruptprozesse wurde die Echtzeitperformance gravierend verbessert. Alle weiteren Versuche werden mit dieser Priorisierung durchgef\"uhrt.

\subparagraph{Anmerkungen zu den weiteren L\"osungsm\"oglichkeiten}

Deaktivieren von IRQ 18 w\"urde zur Folge haben, dass w\"ahrend der Benutzung der Real-time Ethernetschnittstelle nicht mehr von einer anderen Schnittstelle auf das Ger\"at zugegriffen werden kann.

Die letzten beiden L\"osungsans\"atze w\"urden eine Ver\"anderung des Linux Kernel Codes bedeuten, was sofern die \"Anderungen nicht in den Mainstream Kernel \"ubernommen werden, oder in den RT\_ PREEMPT Patch eingepflegt werden, die Wartbarkeit des Systems verschlechtert.

Benedikt Spranger von Linutronix \cite{linutronix} wurde \"uber die Problematik informiert und wird die Implementation einer L\"osung \"ubernehmen.

\subsubsection{V2 Prozessabbild via  RT EventService \"ubertragen}
\label{sec:v2}

F\"ur das Sammeln von Logging Informationen bietet sich der Einsatz des EventServices an. Dieser Versuch implementiert die selbe Funktionalit\"at wie V1 (siehe Kapitel \ref{sec:v1}), allerdings \"uber den RT EventService (siehe Kapitel \ref{sec:rteventservice}).

\paragraph{Softwaredesign}

Auf CPX 2 wird ein NamingService (siehe Kapitel \ref{sec:namingservice})  und ein Real-time EventService gestartet. Die RTCORBA Applikation CPXEventSupplier sendet bei einer \"Anderung an einem digitalen Eingang eine Nachricht mit dem aktuellen Prozessabbild an den RT EventService.

Der CPXEventConsumer wird auf CPX 1 gestartet und registriert sich beim RT EventService f\"ur die Nachrichten, welche von CPX 2 an den RT EventService gesendet werden.

Sobald der RT EventService von CPX 2 eine Nachricht mit dem aktuellen Prozessabbild erh\"alt, leitet er diese an den CPXEventConsumer auf CPX 1 weiter. Der CPXEventConsumer stellt das Prozessabbild auf den digitalen Ausg\"angen dar.

\paragraph{Programmablauf}

\begin{figure}
\begin{center}
\includegraphics[width=\textwidth]{./img/sequenzV2.jpg}
\caption{Sequenzdiagramm V2}
\label{img:sequenzV2}
\end{center}
\end{figure}

Abbildung \ref{img:sequenzV2}: Prozess C (CPXEventProducer) generiert bei Eingang eines Digital Input/Output (DIO) Signals eine Nachricht mit dem aktuellen Prozessabbild. Diese sendet er per RTCORBA an Prozess B, den RT EventService.

Prozess A (CPXEventConsumer) registriert sich beim EventService f\"ur die Nachrichten von Prozess C. Die beim EventService eintreffenden Nachrichten werden an Prozess A weitergeleitet. Dieser schreibt das \"ubermittelte Prozessabbild auf die digitalen Ausg\"ange.

\paragraph{Konfiguration}

\begin{description}
\item[Linux:] Der RT EventService, CPXEventConsumer und CPXEventSupplier ist als RT Prozess priorisiert. Die Priorisierungen der restlichen Prozesse sind den Tabellen in Kapitel \ref{cap:reprio} zu entnehmen.
\item[ACE/TAO:] Die Nachrichten werden mit h\"ochster Priorit\"at versendet und bearbeitet.
\end{description}

\paragraph{Ergebnisse}

\begin{figure}
\begin{center}
  \begin{minipage}[t]{7.5 cm}
	\includegraphics[width=\textwidth]{./img/v2/ohneLast.jpg}
	\caption{CPX1 u. 2 o. Last}
	\label{img:optVerteilungOhneLast2}
  \end{minipage}
  \begin{minipage}[t]{1 cm}
  \end{minipage}
  \begin{minipage}[t]{7.5 cm}
        \includegraphics[width=\textwidth]{./img/v2/mitLast.jpg}
        \caption{CPX1 u. 2 m. xdd, flood ping u. cpuburnP5 belastet}
        \label{img:optVerteilung2}
  \end{minipage}
\end{center}
\hrule
\end{figure}

Die Latenz von etwa $600 \mu s$ in Abbildung \ref{img:optVerteilungOhneLast2} und \ref{img:optVerteilung2} entspricht den Erwartungen. Da die Daten durch den RT EventService (eine weitere RTCORBA Applikation) flie\ss en.

Mit dem auf Seite \pageref{sec:v5} beschriebenen Versuchsaufbau mit einem Real-time Switch (Abb. \ref{img:v4}) wurde dieser Versuch mit 2 CPXEventConsumern noch einmal durchgef\"uhrt. Es wurde eine Differenzzeit von $-260 \mu \dots 138 \mu = 398 \mu s$ zwischen den beiden CPXEventConsumern ermittelt (siehe Abb. \ref{img:2Consumer}). Im Idealfall w\"urden beide CPXEventConsumer die Port\"anderungen synchron darstellen.

\subsubsection{V3 TAO Scheduler}
\label{sec:v3}

Auf der Receiver CPX wurden in zwei Threadpools je ein Objekt gehostet. Ein hoch priorisiertes zum Setzen des digitalen Ausgangports und ein niedrig priorisiertes, welches eine komplexe Berechnung durchf\"uhren kann. 

\"Andert sich bei der Supplier CPX der Zustand eines digitalen Eingangs, wird zuerst die Funktion, welche mit niedriger Priorit\"at die komplexe Berechnung bearbeitet aufgerufen. Anschlie\ss end werden, hoch priorisiert, die digitalen Ausg\"ange der Receiver CPX, entsprechend den digitalen Eing\"angen der Supplier CPX gesetzt.

\paragraph{Konfiguration}
\begin{description}
\item[Threadpools] Jedes Objekt wurde innerhalb eines Threadpools gehostet, der mit entsprechender Priorit\"at angelegt wurde
\item[svc.conf] Durch die Zeile 
\begin{lstlisting}
static RT\_ ORB\_ Loader "-ORBPriorityMapping linear -ORBSchedPolicy SCHED\_ RR -ORBScopePolicy SYSTEM"}
\end{lstlisting} 
verwendet der ORB anstatt des als Standard eingestellten FIFO Schedulers einen Round Robin Scheduler.
\end{description}

\paragraph{Ergebnis}

t.b.d.

\subsubsection{V4 Verhalten bei gr\"o\ss eren Datenmengen}
\label{sec:v4}

V1 (siehe Kapitel \ref{sec:v1}) wurde ver\"andert, so dass mit jedem Prozessabbild eine Logdatei von beliebiger Gr\"o\ss e mit \"ubertragen wird. Es wird gemessen, wie die Latenz von der Datenmenge abh\"angig ist.

\paragraph{Ergebnis}

\begin{figure}
\begin{center}
  \begin{minipage}[t]{7.5 cm}
	\includegraphics[width=\textwidth]{./img/v2-2Consumer.jpg}
	\caption{RT EventService mit 2 Consumern}
	\label{img:2Consumer}
  \end{minipage}
  \begin{minipage}[t]{1 cm}
  \end{minipage}
  \begin{minipage}[t]{7.5 cm}
        \includegraphics[width=\textwidth]{./img/v4/plot.jpg}
        \caption{Abh\"angigkeit Datenmenge - Latenz}
        \label{img:dataLat}
  \end{minipage}
\end{center}
\hrule
\end{figure}

Abbildung \ref{img:dataLat} zeigt, dass bei wachsender Datenmenge die Latenzzeiten von immediate und worst case immer weiter auseinanderlaufen. Da in der Praxis die Informationen, welche in Echtzeit ben\"otigt werden, in der Regel kleiner 1 kiloByte sind, empfiehlt es sich die gr\"o\ss eren Datenmengen von den Echtzeitinformationen zu entkoppeln und getrennt, niedriger priorisiert, zu \"ubertragen.

\subsubsection[V5 geswitchtes Netz mit mehreren Teilnehmern]{V5 geswitchtes Netz mit mehreren Teilnehmern und verschieden priorisierten Verbindungen}
\label{sec:v5}

\begin{figure}
\begin{center}
\includegraphics[width=0.8\textwidth]{./img/versuch4.jpg}
\caption{3 CPXen verbunden mit QoS-Switch}
\label{img:v4}
\end{center}
\hrule
\end{figure}

Damit mehrere CPXen miteinandern kommunizieren k\"onnen. wurde die 1:1 Ethernet Verbindung durch einen Quality of Service (QoS) Switch (Hirschmann Railswitch\footnote{Typ: RS20-0400T1T1SDAE} )ersetzt (siehe Abb. \ref{img:v4}).

\paragraph{Softwaredesign}

Der Server auf CPX 2 stellt einen \"ubermittelten Wert auf einem digitalen Ausgangsport dar und empf\"angt parallel beliebig gro\ss e Strings (zum Beispiel Logdateien).

Auf den anderen CPXen werden Clients gestartet. Ein Client kann in vier verschiedenen Modis gestartet werden. Jeder Modi benutzt ein anderes Interface oder eine Kombination mehrerer Interfaces zur Kommunikation mit dem Server:

\begin{description}
\item[PortAndMessage1] Zwei Funktionen in einem Interface, eine zum \"Ubertragen der Logdatei, eine f\"ur die Portinformation. Zuerst werden mit h\"ochster Priorit\"at die Ports gesetzt, danach mit Niedrigster die Logdatei \"ubertragen.
\item[PortAndMessage2] Logdatei und Portinformationen werden in einem hoch priorisierten Funktionsaufruf gemeinsam \"ubertragen.
\item[MessageOnly] In einer Endlosschleife werden Logdateien \"ubertragen (niedrig priorisiert).
\item[MessageAndPortSeperate] Zwei Interfaces mit je einer Funktion. Ein niedrig priorisiertes zur \"Ubertragung der Logdateien und ein hoch priorisiertes zur \"Ubertragung der Portinformationen.
\end{description}

Der Client auf CPX1 \"ubertr\"agt bei Zustands\"anderungen eines Eingangsports den Wert des digitalen Eingangsports und einen String beliebiger Gr\"o\ss e (PortAndMessage1, PortAndMessage2 MessageAndPortSeperate Mode). Von CPX3 aus versenden teilweise mehrere Clients parallel Strings verschiedener Gr\"o\ss e (MessageOnly Mode). Die Anzahl laufender Supplier auf CPX3 entspricht der Anzahl Logdateiensender in Abbildung \ref{img:v5_0}, \ref{img:v5_1-100} und \ref{img:v5cisco}.

\paragraph{Konfiguration}

\begin{description}
\item[RT\_ PREEMPT Priorisierung] Client und Server sind als RT Prozess priorisiert. Die Priorisierungen der restlichen Prozesse sind den Tabellen in Kapitel \ref{cap:reprio} zu entnehmen.
\item[Policies] Es wurde serverseitig f\"ur jeden Servant ein POA angelegt, bei dem folgende Policies gesetzt wurden:
\begin{itemize}
\item Die RTCORBA Priorit\"aten wurden auf diffServ \cite{diffserv} Priorit\"aten gemapped:
\begin{lstlisting}
RTCORBA::TCPProtocolProperties(ACE_DEFAULT_MAX_SOCKET_BUFSIZ, ACE_DEFAULT_MAX_SOCKET_BUFSIZ, 1, 0, 1, 1 /*enable netw. priority*/ );
\end{lstlisting}
QoS-Switches k\"onnen so konfiguriert werden, dass h\"oher priorisierte Pakete bevorzugt weitergereicht werden.
\item Ein Threadpool stellt die Verf\"ugbarkeit der Ressourcen sicher:
\begin{lstlisting}
RTCORBA::ThreadPoolWithLanes(0 /*Stacksize*/, lanes, 0 /*borrowing*/, 0 /*buffering*/, 0 /*maxBuf*/, 0 /*maxBufSize*/);
\end{lstlisting}
\item Die Priorit\"aten k\"onnen vom Client aus zur Laufzeit definiert werden:
\begin{lstlisting}
RTCORBA::PriorityModel(RTCORBA::CLIENT_PROPAGATED, 0 /*default priority*/);
\end{lstlisting}
\end{itemize}
\item[svc.conf] Es wird Round Robin Scheduling und lineares Priorit\"aten Mapping verwendet:
\begin{lstlisting}
static RT_ORB_Loader "-ORBPriorityMapping linear -ORBSchedPolicy SCHED_RR -ORBScopePolicy SYSTEM"
\end{lstlisting}
\end{description}

\begin{figure}
\begin{center}
\includegraphics[width=0.8\textwidth]{./img/v5/dump-data.png}
\caption{wireshark dump: \"Ubertragung einer niedrig priorisierten Logdatei}
\label{img:diffServData}
\end{center}
\hrule
\end{figure}

Mittels dem Netzwerkanalysetool wireshark und einem Hub wurde \"uberpr\"uft, ob die Priorisierungen korrekt in die Netzwerkprotokolle eingetragen wurden (siehe Abb. \ref{img:diffServData} bis \ref{img:RTCORBAPrioPorts}).

\begin{figure}
\begin{center}
\includegraphics[width=0.8\textwidth]{./img/v5/dump-rtcorbaprio.png}
\caption{wireshark dump: \"Ubertragung eines Prozessabbilds mit h\"ochster RTCORBA Priorit\"at}
\label{img:RTCORBAPrioPorts}
\end{center}
\end{figure}

\begin{figure}
\begin{center}
\includegraphics[width=0.8\textwidth]{./img/v5/dump-tosPrio.png}
\caption{wireshark dump: entsprechend der RTCORBA Priorit\"at wird auch die diffServ Priorit\"at gesetzt}
\label{img:RTCORBAPrioPorts}
\end{center}
\hrule
\end{figure}

\paragraph{Ergebnisse}

Je mehr Traffic mittels \"Ubertragung von Strings auf dem Netz erzeugt wird, desto gr\"o\ss er wird die Latenz beim  Setzen des Wertes. Es besteht die Vermutung, dass der Switch die Priorisierung im diffServ Feld ignoriert. Da der Gro\ss teil der Logdateien nicht von der CPX versendet wird, welche die Prozessabbilde \"ubertr\"agt, wurde eine Portpriorisierung am Hirschmann Switch eingestellt: 

\begin{longtable}[c]{|c|c|l|}
\hline
\textbf{Port} & \textbf{Priorit\"at} & \textbf{Device} \\
\hline
\hline
1 & 7 & CPX 1 \\
\hline
2 & 7 & CPX 2 \\
\hline
3 & 0 & CPX 3 \\
\hline
4 & 0 & PC \\
\hline
\caption{Portpriorisierung, Hirschmann Switch}
\label{tab:portprio}
\end{longtable}

Die Latenz bei der \"Ubertragung des Prozessabbildes \"anderte sich auch bei steigender Datenmenge nur noch geringf\"ugig. Eine Anfrage bei Hirschmann best\"atigte die Vermutung: Die Hardware unterst\"utze zwar diffServ, darum w\"are es im Datenblatt angegeben, doch sei dies in der aktuellen Software Version noch nicht implementiert.

Somit kamen die folgenden Messergebnisse ohne die Einbeziehung des diffServ Feldes zu Stande. Die Ports am Switch waren wie in Tabelle \ref{tab:portprio} beschrieben priorisiert.

\begin{figure}
\begin{center}
  \begin{minipage}[t]{7.5 cm}
	\includegraphics[width=\textwidth]{./img/v5/plot3d-hirschmann.jpg}
	\caption{V5 immediate case}
	\label{img:v5_0}
  \end{minipage}
  \begin{minipage}[t]{7.5 cm}
	\includegraphics[width=0.8\textwidth]{./img/v5/plot1-100.jpg}
	\caption{V5 worst case}
	\label{img:v5_1-100}
  \end{minipage}
\end{center}
\hrule
\end{figure}

Abbildung \ref{img:v5_0}: Werden nur Funktionsaufrufe get\"atigt, aber keine Daten versendet, verhalten sich die verschiedenen Interfacekonfigurationen \"ahnlich. Die \"Ubertragung des zu setzenden Wertes via PortAndMessage2 Interface dauert l\"anger, da der \"ubertragene Wert f\"ur den Ausgangsport erst gesetzt wird, nachdem der komplette String \"ubertragen wurde.

Abbildung \ref{img:v5_1-100}: Bei dieser Messung war der String, welcher parallel zum zu setzenden Wert \"ubertragen wurde, 0 Zeichen lang. Die Strings, welche von CPX 3 aus versendet wurden, sind aus einer 100kByte gro\ss en Textdatei erzeugt worden. Bei dieser Konfiguration ist die worst case Latenz, bei der \"Ubertragung des hoch priorisierten Wertes unabh\"angig vom weiteren Traffic auf dem Netzwerk und der Wahl des Interfaces.

\begin{figure}
\begin{center}
	\includegraphics[width=0.5\textwidth]{./img/v5/plot3d-cisco.jpg}
	\caption{V5 immediate case mit Cisco Switch}
	\label{img:v5cisco}
\end{center}
\hrule
\end{figure}

Da der Hirschmann Switch scheinbar mit der aktuellen Softwareversion noch nicht zuverl\"a\ss ig genug arbeitet, wurde der Versuch erneut mit einem Cisco Catalyst 2955 \cite{catalyst} Switch durchgef\"uhrt. Nach entsprechender Konfiguration beachtet der Cisco Switch die diffServ Angaben. Deshalb war eine Prirorisierung der Ports nicht notwendig. 

Abbildung \ref{img:v5cisco} zeigt, dass sich der Cisco Switch auch bei gr\"o\ss eren Datenmengen deutlich perfomanter verh\"alt, als der zuvor verwendete Hirschmann Switch. Dass die Latenz bei zunehmender Anzahl von Logdateisender und zunehmender L\"ange der Strings (Dateigr\"o\ss e) beim Cisco Switch geringf\"ugig (logarithmischer Ma\ss stab!) h\"oher ist, als beim Hirschmann Switch, d\"urfte daran liegen, dass bei jedem Paket das diffServ Feld eingelesen und bewertet werden mu\ss . Dies ben\"otigt mehr Rechenleistung, als die fixe Priorisierung der physikalischen Ports beim Hirschmann Switch.

\begin{figure}
\begin{center}
	\includegraphics[width=\textwidth]{./img/arbeitsplatz.jpg}
	\caption{Foto: Versuchsaufbau V5 mit Cisco Switch}
	\label{img:v5foto}
\end{center}
\hrule
\end{figure}

\subsection{V6 Prozessabbild \"ubertragen mit Ice}

Ice \cite{ice} ist eine an das CORBA Konzept angelehnte Middleware, siehe Kapitel \ref{sec:ice}. Der Funktionsaufbau, sowie die Funktionalit\"at dieses Versuchs entspricht dem ACE/TAO Versuch in Kapitel \ref{sec:v1} (V1). Es wird nicht auf die Implementierung des Versuchs eingegangen, da dieser Versuch lediglich durchgef\"uhrt wurde, um einen Vergleich zu der Performance des ACE/TAO Frameworks zu haben.

Da Ice keine M\"oglichkeit bietet, Verbindungen, Objekte oder Aufgaben zu priorisieren, eignet es sich nicht f\"ur den geplanten Einsatzzweck.

Die Latenz zwischen Auslesen des Prozessabbildes auf CPX1, \"Ubertragung des Abbildes via Ice an CPX2 und Darstellung des Prozessabbildes auf den digitalen Ausg\"angen betr\"agt $230 \mu s$. ACE/TAO ben\"otigt f\"ur die selbe Aufgabe $400 \mu s$. Durch die in Ice fehlenden zero-copy Features ist anzunehmen, dass sich die Performance von ACE/TAO bei gr\"o\ss eren Datenmengen zumindest nicht weiter von Ice entfernen wird. Siehe hierzu \cite{throughput}.

\subsection{Fazit}

Die Real-time Eigenschaften von ACE/TAO sind stark von der Implementation der Anwendung und der Konfiguration zur Laufzeit abh\"angig. \cite{devguide}, \cite{aceguide} und \cite{pattern} erleichtern den Einstieg. Benutzt man das Framework korrekt, so erzielt es zuverl\"assig eine gute Echtzeitperformance.

Probleme bei der Ende zu Ende Echtzeitperformance sind momentan noch teilweise auf die Netzwerkanbindung des RT\_ PREEMPT Patches zur\"uckzuf\"uhren. Es hat sich gezeigt, dass die Wahl und Konfiguration der Netzwerkkomponenten ma\ss geblich \"uber die Ende zu Ende Performance entscheidet.