% (c) Andreas Hofmeier
% http://www.lgut.uni-bremen.de/an-h/
% http://an-h.de/ oder http://an-h.de.vu/ (ohne Werbung)
\documentclass[11pt]{article}
\usepackage{a4,german}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}
\usepackage{ngerman}
\usepackage[dvips]{graphics}
\usepackage{latexsym}
\usepackage{exscale}
\usepackage{amssymb,amsmath}
%\documentclass[11pt]{report}
%\usepackage{isolatin1}
%\usepackage{german}
\usepackage{epsf}
\usepackage[dvips]{rotating}

\usepackage{longtable}
\usepackage{dcolumn}

\usepackage{listings}

%\usepackage{eurosym}
%\EUR{300}

\usepackage{multicol}
%\usepackage[dvips]{rotating}

%ENDHEAD

\parindent=0pt
\parskip=\baselineskip

%\setcounter{tocdepth}{4}
%\setcounter{secnumdepth}{4}

\pagestyle{plain}
\pagestyle{myheadings}
\markright{\mbox{\bf A. Hofmeier, RDUe Laborversuch NIC Performancemessung}}
%\markboth{\mbox{\bf A. Hofmeier, EMT Laborversuch FS}}{\mbox{\bf A. Hofmeier, EMT Laborversuch FM}}

\begin{titlepage}
\title{-- RDUe Labor --\\Rechnernetze und Datenübertragung\\Laborbericht über Versuch:\\NIC Performancemessung}
\author{Andreas Hofmeier}
%\date{12. Mai 2003}
\date{}
\end{titlepage}


\begin{document}
\maketitle

\begin{center}
\begin{tabular}{rl}

Auftraggeber: & Prof. Dr.-Ing. Kai-Oliver Detken,\\
 & Fachhochschule Bremen \\
Durchführung am: & 19.03.2004, 23.04.2004 und 07.05.2004\\
Ort der Durchführung: & FH Bremen, Flughafenalle 10,\\
 &  Raum: I222 \\
Abgabe am: & 28.07.2004\\
\\
\end{tabular}

Versuchsgruppe

\begin{tabular}{rcll}
Andreas Hofmeier  & & & \\
Axel Schmidt      & & & \\



\end{tabular}
\end{center}



\begin{abstract}
  .  \\In diesem Versuch wurde die Performance zweier mit einem CAT-5
  Cross-Over-Cable verbundenden NICs (Netzwerkkarten) gemessen. Also
  die Zeit in welcher eine gewisse Menge an Daten von Rechner A mit
  NIC A zu Rechner B mit NIC B übertragen wurde.
  \\\\
  Die Messungen erfolgten mit einem speziellem Programm, welches
  direkt TCP und UDP-Pakete versendete. Um Vergleiche anstellen zu
  können wurden die Messungen mit verschiedenen Sende-/Empfangspuffern
  und unterschiedlichen Betriebssystemen durchgeführt.

\end{abstract}
\newpage

\tableofcontents
\newpage



\section{Versuchsziele}

Mit diesem Versuch sollte geklärt werden in wie weit sich Änderungen
des Sende-/Empfangspuffers und das verwendete Betriebssystem auf die
Datenübertragungsrate auswirkt. Es sollte ein Performancetest der
Netzwerkkarten (NICs) und des Netzwerkes an sich (in diesem Fall ein
CAT-5 Cross-Over-Cable) vorgenommen werden. Die Messung der
Performance der Anwenderprogramme bzw. der Protokolle dieser war nicht
erwünscht. Des weiteren sollte ein Grundverständnis des
Netzwerkstacks (TCP/UDP über Ethernet) erlangt werden.


\section{Vorbetrachtungen}

\subsection{Schichten}

\begin{tabular}{|c|c||c|c|}

\hline
Schicht & OSI-Schicht & \multicolumn{2}{c|}{In unserem Fall verwendet} \\
\hline
\hline
& Application Layer & \multicolumn{2}{c|}{} \\
Anwendungsschicht & Presentation Layer & \multicolumn{2}{c|}{netperf} \\
& Session Layer & \multicolumn{2}{c|}{} \\
\hline
Transportschicht & Transportschicht & \hspace{0.6cm}TCP\hspace{0.6cm} & UDP \\
\hline
Internetschicht & Netzwerkschicht & \multicolumn{2}{c|}{IP} \\
\hline
Netzwerkschicht & Sicherungsschicht & \multicolumn{2}{c|}{Ethernet} \\
		 & Bitübertragungsschicht & \multicolumn{2}{c|}{} \\
\hline

\end{tabular}

In diesem Abschnitt wurden teilweise Texte von\\ {\tt
http://n.ethz.ch/student/stammt/doc/Inhalt.html} übernommen, teilweise
überarbeitet.

\subsubsection{Ethernet}

Ein Ethernet-Paket ist wie folgt aufgebaut:

{\tt\tiny
\begin{lstlisting}
Bits | F E D C|B A 9 8||7 6 5 4|3 2 1 0 | F E D C|B A 9 8||7 6 5 4|3 2 1 0 |
-----|---------------------------------------------------------------------|
     | 1 0 1 0 1 0 1 0  1 0 1 0 1 0 1 0   1 0 1 0 1 0 1 0  1 0 1 0 1 0 1 0 |
     |---------------------------------------------------------------------|
     | 1 0 1 0 1 0 1 0  1 0 1 0 1 0 1 0   1 0 1 0 1 0 1 0  1 0 1 0 1 0 1 1 |
     |---------------------------------------------------------------------|
     |       Destination-                                                  |
     |         Adresse                  +----------------------------------|
     |                                  |         Source-                  |
     |----------------------------------+         Adresse                  |
     |                                                                     |
     |----------------------------------+----------------------------------|
     |              Typ                 |          ...Daten...             |
     |----------------------------------+          ...Daten...             |
     |                           ...Daten...                               |
     |          ...Daten...             +----------------------------------|
     |          ...Daten...             |              CRC                 |
-----|----------------------------------+----------------------------------|
Quelle: http://n.ethz.ch/student/stammt/doc/Netzwerk/Ethernet.html
\end{lstlisting}
}

Zuerst wird die so genannte Preamble übertragen, welche aus 7 Bytes
mit dem Bitmuster 10101010 (Hexadezimal 0xAA) und einem Byte mit
Muster 10101011 (0xAB) besteht. Dieses Preamble wird benutzt, um den
Empfänger zu synchronisieren. Wenn die Preamble defekt ist, kann davon
ausgegangen werden, dass das restliche Paket ebenfalls unleserlich
ist.  Bei ordnungsgemäßer Übertragung folgen jetzt die beiden
6-Byte-(48-Bit)-MAC-Adressen für das Ziel und die Quelle.  Daraufhin
folgen 16 Bit mit dem Typ des nächst höheren Protokolls (z.B. IP).
Nun werden die eigentlichen Nutzdaten übertragen.  Zum Schluss wird
noch eine 16-Bit-CRC-Prüfsumme angehängt.


\subsubsection{IPv4}

IP ist die Abkürzung für ``Internet-Protokoll''. Es ist zuständig für
das korrekte versenden von Daten von einem Punkt zu einem anderen. Die
Endpunkte werden dabei durch IP-Adressen angegeben. Diese Adressen
bestehen aus 4 Byte-Zahlen, wie zum Beispiel 233.144.0.111.

Der Header des IP-Protokolls ist folgendermasse aufgebaut:
{\tt\tiny
\begin{lstlisting}
Bits | F E D C|B A 9 8||7 6 5 4|3 2 1 0 | F E D C|B A 9 8||7 6 5 4|3 2 1 0 |
-----|--------|-------||----------------|----------------------------------|
     |Version |H-Laeng||  Service-Typ   |              Laenge              |
     |--------+-------++----------------|------+---------------------------|
     |                ID                | Flgs |     Fragment-Offset       |
     |----------------++----------------|------+---------------------------|
     |       TTL      ||höheresProtokoll|             Checksum             |
     |----------------++----------------+----------------------------------|
     |                          Source-IP-Adresse                          |
     |---------------------------------------------------------------------|
     |                           Ziel-IP-Adresse                           |
     |---------------------------------------------------------------------|
     |                           ...Optionen...                            |
-----|---------------------------------------------------------------------|
     |                             ...Daten...                             |
Quelle: http://n.ethz.ch/student/stammt/doc/Netzwerk/IP.html
\end{lstlisting}
}

\begin{itemize}


\item[-] Version (4 Bit): Gibt an, um welche Version von IP es sich handelt
(Momentan normalerweise v4).
\item[-] H-Laenge (4 Bit): Die Header-Länge gibt an, wieviele 32-Bit-Zeilen der gesamte Header besitzt
(wird für zusätzliche Optionen benutzt).
\item[-] Service-Typ (8 Bit): Gibt an, um welche Art von Daten es sich handelt.
\item[-] Laenge (16 Bit): Gibt an, wieviele Bytes das gesamte Paket enthält.
\item[-] ID (16 Bit): Gibt an, um welches Paket es sich handelt.
\item[-] Flgs (3 Bit): Flags, werden für die Fragmentierung benutzt.
\item[-] Fragment-Offset (13 Bit): Gibt an, an welcher Stelle das Fragment eingefügt werden muss (in
8 Bytes).
\item[-] TTL (8 Bit): Die Time-To-Live gibt an, wieviele Hops das Paket noch weitergesendet werden
darf.
\item[-] höheresProtokoll (8 Bit): Gibt an, welches Protokoll im nächst höheren Layer gebraucht wird.
\item[-] Checksum (16 Bit): Hier wird die Checksumme gespeichert (wird zu Korrektheitsüberprüfung
gebraucht).
\item[-] Source-IP-Adresse (32 Bit): Gibt an, von welcher IP-Adresse das Paket kam.
\item[-] Ziel-IP-Adresse (32 Bit): Gibt an, zu welcher IP-Adresse das Paket gesendet werden soll.
%\item[-] Optionen (je 32 Bit): Optionen

\end{itemize}





\subsubsection{UDP}

Das ``User Datagram Protocol'', welches verbindungslos arbeitet, ist
sehr einfach aufgebaut. Es erlaubt Daten in Form von einzelnen und
unahbängigen Datergrammen über ein Netzwerk zu schicken. Die
Anwendungsschicht muss sicherstellen, dass alle Pakete angekommen sind
und in der richtigen Reihenfolge vorliegen. Das einzige was UDP prüft
ist die Paketintegrität an Hand der Prüfsumme. Ein UDP-Paket ist
folgendermassen aufgebaut:

{\tt\tiny
\begin{lstlisting}
Bits | F E D C B A 9 8 7 6 5 4 3 2 1 0 | F E D C B A 9 8 7 6 5 4 3 2 1 0 |
-----|---------------------------------|---------------------------------|
     |         Source-Port             |           Dest.-Port            |
     |---------------------------------|---------------------------------|
     |            Laenge               |            checksum             |
-----|---------------------------------+---------------------------------|
     |                           ...Daten...                             |
Quelle: http://n.ethz.ch/student/stammt/doc/Netzwerk/UDP.html
\end{lstlisting}
}

\begin{itemize}

\item[-] Source- und Destination-Port (je 16 Bit): Geben an, von welchem Port sie gesendet wurden,
und auf welchen Port sie gesendet werden.
\item[-] Laenge (16 Bit): Gibt die Anzahl Bytes (Maximal 65535) des Datenblockes an.
\item[-] Checksum (16 Bit): Ist eine Zahl, die durch die Addition der Einerkomplemente aller
16-Bit-Zahlen des Headers (ohne die Checksum) errechnet wird.

\end{itemize}


\subsubsection{TCP}


Das ``Transmission Control Protocol'' ist speziell entwickelt worden,
um große Dateien in kleinere Pakete zu unterteilen und diese mittels
Pipelining über ein Netzwerk zu senden. Standardisiert ist TCP durch
RFC 793, 1122, 1323, 2018 und 2581. TCP-Pakete sind folgendermassen
aufgebaut:

\newpage
{\tt\tiny
\begin{lstlisting}
Bits | F E D C|B A 9 8||7 6 5 4|3 2 1 0 | F E D C|B A 9 8||7 6 5 4|3 2 1 0 |
-----|----------------------------------|----------------------------------|
     |         Source-Port              |            Dest.-Port            |
     |----------------------------------+----------------------------------|
     |                           Sequenz-Nummer                            |
     |---------------------------------------------------------------------|
     |                              ACK-Nummer                             |
     |--------+-------------------------+----------------------------------|
     |Head-Len| ----------- U A P R S F |    Empfaenger-Fenstergroesse     |
     |--------+-------------------------|----------------------------------|
     |          Checksum                |     Wichtige-Daten-Pointer       |
     |----------------------------------|----------------------------------|
     |                           ...Optionen...                            |
-----|---------------------------------------------------------------------|
     |                             ...Daten...                             |
Quelle: http://n.ethz.ch/student/stammt/doc/Netzwerk/TCP.html
\end{lstlisting}
}

\begin{itemize}


\item[-] Source- und Destination-Port (je 16 Bit): Geben an, von welchem Port sie gesendet wurden,
und auf welchen Port sie gesendet werden.
\item[-] Sequenz-Nummer (32 Bit): Gibt an, welche Byteposition das Paket beschreibt.
\item[-] ACK-Nummer (32 Bit): Gibt an, welche Nummer das ACK-Signal besitzt.
\item[-] Head-Len (4 Bit): Gibt an, wieviele Zeilen (  32 Bit) der Header enthält (wird benutzt für
Optionen).
\item[-] Flags:
\begin{itemize}
\item[-] U: Urgent Data, ist gesetzt, falls in dem Datenblock wichtige Daten enthalten sind (wird
aber grundsätzlich nicht benutzt).
\item[-] A: ACK valid, ist gesetzt, falls die ACK-Nummer gültig ist.
\item[-] P: Push data now, ist gesetzt, falls ??? (wird grundsätzlich nicht benutzt).
\item[-] R, S, F: RST, SYN, FIN, wird benutzt, um die Verbindung auf- und abzubauen.
\end{itemize}
\item[-] Empfaenger-Fenstergroesse (16 Bit): Enthält die Anzahl Bytes, die der Empfänger akzeptieren
wird. 
\item[-] Checksum (16 Bit): Ist eine Zahl, die durch die Addition der Einerkomplemente aller
16-Bit-Zahlen des Headers (ohne die Checksum) errechnet wird.
\item[-] Wichtige-Daten-Pointer (16
Bit): Der Zeiger auf die so überaus wichtigen Daten (falls das U-Flag
gesetzt ist).
%\item[-]  Optionen (je 32 Bit): Siehe unten.
\end{itemize}

Die Sequenz- und ACK-Nummer wird wie folgt verwendet: Wenn der Client
ein Paket sendet, so enthält Sequenz-Nummer die Byte-Position
innerhalb der gesamten Datei. ACK enthält einen
Kontrollwert. Wenn nun der Server das Paket korrekt erhalten hat, so
sendet er ein ACK-Paket zurück, welches als ACK-Wert das nächste zu
sendende Byte (errechnet mittels Byte-Position plus Datenblock-Länge)
enthält und als Sequenznummer den Kontrollwert von vorher. Dadurch
kann der Client sehen, dass das Paket nun abgehakt werden kann, und er
sieht zudem, ab welcher Byteposition er als nächstes senden muss.




\section{Versuchsaufbau}

Um die Performance des Netzwerkes möglichst direkt zu messen, wie
gefordert, kam ein spezielles Testprogramm zum Einsatz:
Netperf. Dieses Programm setzt direkt auf TCP bzw. UDP Sockets
auf sendet bzw. empfängt Daten und misst die Zeit, die das Netzwerk
braucht um diese Daten zu übertragen. Daraus wird dann die
Datenübertragungsrate bzw. Geschwindigkeit berechnet.

\subsection{Verwendete Computer}

Es kamen zwei PCs zum Einsatz, welche folgende Charakteristiken
aufwiesen:

\begin{itemize}

\item[-] CPU Typ: AMD Athlon XP, 1544 MHz (5.75 x 269) 1800+
\item[-] Motherboard: Asus A7V266-EX (5 PCI, 1 AGP Pro, 1 ACR, 3 DIMM)
\item[-] Motherboard Chipsatz: VIA VT8366A Apollo KT266A
\item[-] Systembus: PCI-32 mit 33MHz
\item[-] Arbeitsspeicher: 128 MB (DDR SDRAM)
\item[-] BIOS Typ: Award Medallion (01/23/02)
\item[-] Grafikkarte: 3D Prophet 4000XT TV Out (32 MB)
\item[-] 3D-Beschleuniger: ST PowerVR Kyro
\item[-] Soundkarte: C-Media CMI8738 Audio Chip
\item[-] Diskettenlaufwerk
\item[-] Festplatte (40 GB, 7200 RPM, Ultra-ATA/100)
\item[-] ATAPI CD-R/RW 24X10 (24x/10x/40x CD-RW)
\item[-] PIONEER DVD-ROM DVD-116 (16x/40x DVD-ROM)

\end{itemize}

\subsubsection{Netzwerkkarten}

\begin{itemize}

\item[-] Hersteller: 3Com
\item[-] Typ: 3Com Etherlink XL 3C905C-TX-M
\item[-] Geschwindigkeit: 10/100 MBps
\item[-] Bus: PCI
\item[-] Funktionallität: IEEE 802.1p (Prioritätsvergabe für Datenübertragung)
\item[-] Sonstiges: Passive (d.h. kein Prozessor auf der Netzwekkarte)
\item[-] IPs: 194.94.26.55 und 194.94.26.56
\item[-] MACs: 00:04:76:D6:83:A6 und 99:04:76:D6:83:A4

\end{itemize}

\subsubsection{Betriebssysteme}

GNU Linux

\begin{itemize}

\item[-] Distribution: SuSE 9.0
\item[-] Kernel: {\tt Linux 2.4.21-199-athlon \#1 Fri Mar 12 08:24:04 UTC 2004 i686 athlon i386}
\item[-] Socks-Implementation: BSD Sockets

\end{itemize}


Windows

\begin{itemize}

\item[-] Microsoft$^{tm}$ Windows 2000 Professional
\item[-] Codename: Cairo
\item[-] Service Pack 4
\item[-] Sprache: Deutsch (Deutschland)
\item[-] Kerneltyp: Uniprocessor Free
\item[-] Version: 5.0.2195 (Win2000 Retail)
\item[-] Treiber für Netzwerkkarte: EL90BC
\item[-] Socks-Implementation: WinSocks (WINSOCK.DLL bzw. WSOCK32.DLL)

\end{itemize}


\section{Versuchsdurchführung}

Es wurden zwei Computer (PCs) über ein CAT-5 Cross-Over-Cable
verbunden. Auf dem Server wurde jeweils netserver gestartet. Auf dem
Client wurde jeweils netperf gestartet, welchem die Parameter für die
aktuelle Messung übergeben wurden.



\subsection{Netperf}

Version unter Linux:

{\tt
netperf.c (c) Copyright 1993-2003 Hewlett-Packard Company. Version 2.2pl3
netserver.c (c) Copyright 1993-2003 Hewlett-Packard Co. Version 2.2pl3
}



\paragraph{Parameter von Server (netserver)}

Netserver wird ohne Parameter aufgerufen. Unter Linux geht das
Programm selbstständig in den Hintergrund und läuft solange bis es
(z.B. mit kill) abgeschossen wird. Unter Windows muss des Programm bei
jeder Messung neu gestartet werden.


\paragraph{Parameter von Client (netperf)}

netperf wurde wie folgt aufgerufen:

\small{\tt
netperf -H <ip> [-t UDP\_STREAM] [-P0] - - -s <l.b.> -S <r.b.> -m <p.s.>\\
}

\begin{tabular}{ll}

ip: & IP-Adresse des Zielgerätes auf dem netserver läuft \\
-t UDP\_STREAM & UDP-Pakete senden. Default: TCP-Pakete. \\
-P0: & gibt nur die Messwerte aus und unterlasse die Ausgabe des Headers.\\
l.b.: & Local Send/Receive Buffer Size von 16, 20, 24, ..., 64kByte\\
r.b.: & Remote Send/Receive Buffer Size von 16, 20, 24, ..., 64kByte\\
p.s.: & Paket Größe: 64, 576, 1500, 65536 Byte\\

\end{tabular}


\subsection{Messreihen}

Es wurden vier Betriebssystem-Combinationen getestet:

\begin{tabular}{|r|c|c|}

\hline
Kennung & Server & Client \\
\hline
\hline
LL & GNU Linux & GNU Linux \\
WL & Windows & GNU Linux \\
LW & GNU Linux & Windows \\
WW & Windows & Windows \\
\hline

\end{tabular}

In jeder Kombination wurden jeweils acht Messreihen mit den
Paketgrößen 64, 576, 1500, 65536 Byte und TCP oder UDP
durchgeführt. Da UDP keine 65536 Byte großen Pakete verarbeiten kann,
wurden hier 64512 Bytes verwendet.

\newpage
In jeder Messreihe wurden die Sende- und Empfangepuffer jeweils gleich
auf folgende Werte eingestellt: 

\begin{enumerate}

\item 16384 Byte = 16 kByte
\item 20480 Byte = 20 kByte
\item 24576 Byte = 24 kByte
\item 28672 Byte = 28 kByte
\item 32768 Byte = 32 kByte
\item 36864 Byte = 36 kByte
\item 40960 Byte = 40 kByte
\item 45056 Byte = 44 kByte
\item 49152 Byte = 48 kByte
\item 53248 Byte = 52 kByte
\item 57344 Byte = 56 kByte
\item 61440 Byte = 60 kByte
\item 65536 Byte = 64 kByte

\end{enumerate}


\subsection{Bemerkungen}


Die Cross-Over-Verbindung über das Patchfeld funktionierte nicht. Es
wurde daher ein ``normales'' 2m Cross-Over-Kabel verwendet.

Alle Messungen liefen 10 Sekunden. Dies ist die default-Einstellung
bei Netperf. Die unter GNU Linux durchgeführten Messungen hielten sich
mit 10 bis 10.01 Sekunden ziemlich genau an die Vorgaben. Unter Windows
variierte die Messdauer zwischen 11 und 19 Sekunden.

Die Messungen zwischen den Windows-Computern (WW) gestaltete sich
leider sehr schwierig. Wir hatten mit verdächtig langsam laufenden
Computern sowie mit massieven Systemausfällen zu kämpfen, so dass wir
die Messung, welche bereits auf einen dritten Labortermin gelegt
werden mußte, zum Schluß aufgeben mußten. Die Messungen an denen
Windows nur zum Teil beteiligt war liefen bis auf einige Ausfälle
vergleichsweise gut.


\section{Versuchsergebnisse}

%\subsection{LL -- Server: GNU Linux; Client: GNU Linux}

\begin{tabular}{|r||p{0.735cm}|p{0.735cm}|p{0.735cm}|p{0.735cm}|p{0.735cm}|p{0.735cm}|p{0.735cm}|p{0.735cm}|l|}

\hline
   \multicolumn{9}{|c|}{LL -- Server: GNU Linux; Client: GNU Linux} & Kombination \\
\hline
\hline
Buffer &  \multicolumn{4}{c|}{TCP}  & \multicolumn{4}{c|}{UDP} & Protokoll \\
größe &	64 &	576 &	1500 &	65536 &	64 &	576 &	1500 &	65536 & Paketgröße \\
\hline
16 &	88.35 &	93.80 &	93.93 &	94.06 &	48.51 &	89.59 &	92.27 &	95.90 & Messungen \\
20 &	89.93 &	93.67 &	93.88 &	93.94 &	48.45 &	89.64 &	92.03 &	95.79 & \\
24 &	90.79 &	93.85 &	94.03 &	94.05 &	48.49 &	89.68 &	92.24 &	96.05 & \\
28 &	91.12 &	93.91 &	94.07 &	94.05 &	48.58 &	89.68 &	92.25 &	96.05 & \\
32 &	93.89 &	93.93 &	94.09 &	94.06 &	46.86 &	89.69 &	92.27 &	96.05 & \\
36 &	93.93 &	93.96 &	94.12 &	94.07 &	48.51 &	89.70 &	92.28 &	96.05 & \\
40 &	93.97 &	93.97 &	93.97 &	94.06 &	48.46 &	89.71 &	92.29 &	96.10 & \\
44 &	93.99 &	93.99 &	94.00 &	94.03 &	48.38 &	89.72 &	92.31 &	96.10 & \\
48 &	93.99 &	93.99 &	94.01 &	94.10 &	45.40 &	89.67 &	92.28 &	96.15 & \\
52 &	94.01 &	94.04 &	94.04 &	94.09 &	45.58 &	89.67 &	92.29 &	96.15 & \\
56 &	94.02 &	94.03 &	94.06 &	94.09 &	44.29 &	89.67 &	92.30 &	96.10 & \\
60 &	94.02 &	94.04 &	94.07 &	94.10 &	43.10 &	89.66 &	87.14 &	96.15 & \\
64 &	94.04 &	94.04 &	94.09 &	94.10 &	41.58 &	89.67 &	87.14 &	96.15 & \\
\hline
$\phi$ &	92.77 &	93.94 &	94.03 &	94.06 &	46.63 &	89.67 &	91.47 &	96.06 & Durchschnitt \\
\hline

\end{tabular}


%\subsection{WL -- Server: Windows; Client: GNU Linux}

\begin{tabular}{|r||p{0.735cm}|p{0.735cm}|p{0.735cm}|p{0.735cm}|p{0.735cm}|p{0.735cm}|p{0.735cm}|p{0.735cm}|l|}

\hline
   \multicolumn{9}{|c|}{WL -- Server: Windows; Client: GNU Linux} & Kombination \\
\hline
\hline
Buffer &  \multicolumn{4}{c|}{TCP}  & \multicolumn{4}{c|}{UDP} & Protokoll \\
größe &	64 &	576 &	1500 &	65536 &	64 &	576 &	1500 &	65536 & Paketgröße \\
\hline
16 &	93.45 &	93.83 &	93.95 &	94.02 &	02.57 &	89.40 &	92.35 &	 & Messungen \\
20 &	93.78 &	93.96 &	93.96 &	94.11 &	02.53 &	89.71 &	92.36 &	 & \\
24 &	93.94 &	93.93 &	94.02 &	94.12 &	02.04 &	89.58 &	92.37 &	56.31 & \\
28 &	93.91 &	93.91 &	94.01 &	94.12 &	02.71 &	89.72 &	92.38 &	96.15 & \\
32 &	94.08 &	94.13 &	94.13 &	94.01 &	02.48 &	89.68 &	92.37 &	95.94 & \\
36 &	93.94 &	93.83 &	94.05 &	94.10 &	02.79 &	89.72 &	92.38 &	96.20 & \\
40 &	93.97 &	93.97 &	93.97 &	94.12 &	02.63 &	89.73 &	92.38 &	96.20 & \\
44 &	93.99 &	93.98 &	94.01 &	94.12 &	02.48 &	89.73 &	92.40 &	96.20 & \\
48 &	94.13 &	94.12 &	94.12 &	94.13 &	02.52 &	89.75 &	92.38 &	96.20 & \\
52 &	94.12 &	94.13 &	94.13 &	94.13 &	02.58 &	89.75 &	92.38 &	96.20 & \\
56 &	94.02 &	94.05 &	94.06 &	94.12 &	02.62 &	89.75 &	92.21 &	96.20 & \\
60 &	94.11 &	94.12 &	94.13 &	94.13 &	02.61 &	89.75 &	01.89 &	96.20 & \\
64 &	94.13 &	94.13 &	94.13 &	94.13 &	02.60 &	89.75 &	 &	96.20 & \\
\hline
$\phi$ &	93.97 &	94.01 &	94.05 &	94.10 &	2.55 &	89.69 &	84.82 &	92.55 & Durchschnitt \\
\hline

\end{tabular}


%\subsection{LW -- Server: GNU Linux; Client: Windows}

\begin{tabular}{|r||p{0.735cm}|p{0.735cm}|p{0.735cm}|p{0.735cm}|p{0.735cm}|p{0.735cm}|p{0.735cm}|p{0.735cm}|l|}

\hline
   \multicolumn{9}{|c|}{LW -- Server: GNU Linux; Client: Windows} & Kombination  \\
\hline
\hline
Buffer &  \multicolumn{4}{c|}{TCP}  & \multicolumn{4}{c|}{UDP} & Protokoll \\
größe &	64 &	576 &	1500 &	65536 &	64 &	576 &	1500 &	65536 & Paketgröße \\
\hline
16 &	90.44 &	91.79 &	90.54 &	95.00 &	38.29 &	76.92 &	65.38 &	 & Messungen \\
20 &	88.61 &	91.75 &	90.61 &	94.95 &	38.65 &	77.59 &	65.11 &	 & \\
24 &	84.19 &	91.74 &	90.63 &	95.00 &	38.74 &	77.83 &	65.15 &	 & \\
28 &	91.36 &	91.86 &	90.55 &	95.00 &	38.77 &	77.88 &	65.40 &	 & \\
32 &	89.83 &	91.81 &	90.55 &	95.00 &	38.75 &	78.19 &	65.10 &	 & \\
36 &	89.41 &	91.98 &	90.63 &	94.95 &	38.86 &	78.56 &	65.17 &	 & \\
40 &	82.98 &	91.89 &	90.64 &	95.00 &	39.00 &	78.37 &	65.16 &	92.54 & \\
44 &	87.51 &	91.95 &	90.64 &	95.00 &	39.43 &	79.90 &	65.21 &	92.54 & \\
48 &	87.13 &	91.98 &	90.64 &	94.95 &	39.15 &	80.36 &	65.14 &	92.48 & \\
52 &	87.19 &	91.94 &	90.65 &	95.00 &	39.30 &	80.55 &	65.17 &	92.48 & \\
56 &	90.98 &	91.93 &	90.62 &	95.00 &	39.12 &	80.29 &	65.07 &	92.54 & \\
60 &	78.66 &	91.91 &	90.63 &	94.95 &	39.39 &	81.14 &	65.04 &	92.54 & \\
64 &	89.80 &	94.43 &	93.97 &	95.00 &	39.59 &	81.11 &	65.02 &	92.48 & \\
\hline
$\phi$ &	87.55 &	92.07 &	90.87 &	94.98 &	39.00 &	79.13 &	65.16 &	92.51 & Durchschnitt \\
\hline

\end{tabular}


%\subsection{WW -- Server: Windows; Client: Windows}

\begin{tabular}{|r||p{0.735cm}|p{0.735cm}|p{0.735cm}|p{0.735cm}|p{0.735cm}|p{0.735cm}|p{0.735cm}|p{0.735cm}|l|}

\hline
   \multicolumn{9}{|c|}{WW -- Server: Windows; Client: Windows} & Kombination \\
\hline
\hline
Buffer &  \multicolumn{4}{c|}{TCP}  & \multicolumn{4}{c|}{UDP} & Protokoll \\
größe &	64 &	576 &	1500 &	65536 &	64 &	576 &	1500 &	65536 & Paketgröße \\
\hline
16	& 0.20	& 0.21	& 0.21	& 0.19	& 	& 	& 	& & Messungen \\
20	& 0.21	& 0.21	& 0.21	& 0.24	& 	& 	& 	& & \\
24	& 0.21	& 0.21	& 0.20	& 0.14	& 	& 	& 	& & \\
28	& 0.20	& 0.22	& 0.20	& 0.19	& 	& 	& 	& & \\
32	& 0.20	& 0.22	& 0.20	& 	& 	& 	& 	& & \\
36	& 0.20	& 0.22	& 0.21	& 	& 	& 	& 	& & \\
40	& 0.21	& 0.19	& 0.21	& 	& 	& 	& 	& & \\
44	& 0.19	& 0.21	& 0.21	& 	& 	& 	& 	& & \\
48	& 0.21	& 0.20	& 0.21	& 	& 	& 	& 	& & \\
52	& 0.20	& 0.22	& 0.20	& 	& 	& 	& 	& & \\
56	& 0.20	& 0.20	& 0.20	& 	& 	& 	& 	& & \\
60	& 0.20	& 0.20	& 0.19	& 	& 	& 	& 	& & \\
64	& 0.21	& 0.21	& 0.21	& 	& 	& 	& 	& & \\
\hline
$\phi$ & 0.20	& 0.21	& 0.20	& 0.19	& 0.00	& 0.00	& 0.00	& 0.00 & Durchschnitt\\
\hline

\end{tabular}

Übersich über die Durchschnittswerte der Messungen:

\begin{tabular}{|r||p{0.82cm}|p{0.82cm}|p{0.82cm}|p{0.82cm}|p{0.82cm}|p{0.82cm}|p{0.82cm}|p{0.82cm}|}
\hline
Protokoll: &	\multicolumn{4}{c|}{TCP} & \multicolumn{4}{c|}{UDP} \\
Paketgröße: &	64 &	576 &	1500 &	65536 &	64 &	576 &	1500 &	65536\\
\hline
LL &	92.77 &	93.94 &	94.03 &	94.06 &	46.63 &	89.67 &	91.47 &	96.06 \\
WL &	93.97 &	94.01 &	94.05 &	94.10 &	02.55 &	89.69 &	84.82 &	92.55 \\
LW &	87.55 &	92.07 &	90.87 &	94.98 &	39.00 &	79.13 &	65.16 &	92.51 \\
WW &	00.20	& 00.21	& 00.20	& 00.19	& 	& 	&	& \\
\hline
\end{tabular}

Erstaunlich ist, dass die Kombination Server: Windows und Client:
Linux im Schnitt etwas schneller bei der TCP-Übertragung war, als
Linux mit Linux. In allen anderen Kombinaionen hatte Linux mit Linux
die Nase vorn. Bei der UDP-Übertragung und bei kleinen Paketgrößen
deutlicher als bei TCP.

Bei der Datenübertragung der Windows-zu-Windows-Messung ging garnichts
mehr, und dass an beiden Laborveranstaltungen, an denen die Messung
versucht wurde.  Die Messergebnisse aus dieser Messung sind
unrealistisch klein. Im Schnitt 0.2MBps auf einer 100MBps-Strecke sind
etwas wenig.

\section{Versuchsauswertung}

Da die Messungen an denen Microsoft$^{tm}$-Produkte beteiligt waren
Probleme bereiteten und unvollständig sind, verwende ich hier die
Messergebnisse, welche mit Hilfe von Linux gewonnen wurden.

\subsection{Auswirkung der Paketgröße}

Wie erwartet stieg die Übertragungsgeschwindigkeit mit steigender
Paketgröße. Dies ist darauf zurückzuführen, dass kleine Paketen viel
Overhead verursachen.

Wenn also 100 Einheiten Daten übertragen werden sollen, können diese
in 100 Paketen zu je einer Dateneinheit, in 10 Paketen zu je 10
Dateneinheiten oder in 1 Paket mit 100 Dateneinheiten verschickt
werden. Wenn man nun annnimmt, dass je Paket eine Dateneinheit zur
Verwaltung hinzu kommt, ist schnell zu sehen, dass der Overhead bei
den kleinen Paketen 100 Dateneinheiten beträgt, also 50\%. Im besten
Fall, mit 100 Dateneinheiten in einem Paket, liegt er bei einer
Dateneinheit, was etwas weninger als einem Prozent entspricht.

\centerline{
\epsfxsize=13.5cm\epsffile{NICP_UeberZUgr.eps}
}

In diesem Diagramm wurden die Mittelwerte aus der Linux zu Linux -
Messung dargestellt. Es ist zu erkennen, dass bei steigenden
Paketgrößen mehr Daten in weniger Zeit übertragen wurden -- die
Datenübertragungsrate also mit steigender Paketgröße steigt. Bei der
TCP-Messung ist diese Entwicklung nur schwach zu erkennen. Die
Übertragungsrate steigt dort von 92.77 MBps bei 64Byte Paketgröße auf
94.06MBps bei 65kByte Paketen. Bei UDP-Paketen ist diese Entwicklung
wesentlich ausgeprägter.

Das ist, von der Protokollseite her betrachtet, eher verwunderlich,
da TCP-Pakete einen wesentlich größeren Header haben. Anscheinent ist
die TCP-Verarbeitung bei Linux leistungsstärker bei kleinen Paketen
als die UDP-Verarbeitung, was diesen Effekt erklären könnte.


\subsection{Auswirkung der Puffergrößen}

Die Auswirkung der eingestellten Sende- und Empfangspuffer ist
lediglich bei den 64-Byte-Paketen zu erkennen. Bei den anderen
Paketgrößen sind keine nennenswerten Auswirkungen zu erkennen.

\centerline{
\epsfxsize=13.5cm\epsffile{NICP_UeberZUbugr.eps}
}

Wie in dem Diagramm zu erkennen ist, steigt die Leistung bei TCP mit
größerwerdenen Puffern. Bei UDP verhält sich dies genau anders herum. Eine
mögliche Erklärung ist, dass die TCP-Pakete in einem Stream gesendet
wurden. Also Netperf einen TCP-Stream öffnete und Pakete in diesen
sendete. So konnte der Puffer gut ausgenutzt werden, was zu weniger
Zugriffen von Netperf zum Betriebssystem führte. Die Sättigungsgrenze
war hier allerdings schnell erreicht.

\end{document}
