letzte änderungen

bericht/bs/bs.tex

@@ -3,13 +3,11 @@
 \subsection{Wahl des Betriebsystems}
 \label{sub:wahl_des_betriebsystems}
 
-Wir haben \href{http://www.archlinux.org/}{Arch Linux} als Betriebssystem gewählt.
-
-Es hat mit \emph{Systemd} ein modernes und robustes init-System. Systemd verwaltet Abhängigkeiten zwischen den verschiedenen Systemdiensten. Gestartete Dienste werden überwacht und können im Fehlerfall neu gestartet werden.
+Wir haben \href{http://www.archlinux.org/}{Arch Linux} als Betriebssystem gewählt. Es hat mit \emph{Systemd} ein modernes und robustes init-System. Systemd verwaltet Abhängigkeiten zwischen den verschiedenen Systemdiensten. Gestartete Dienste werden überwacht und können im Fehlerfall neu gestartet werden.
 Das Logging delegiert \emph{Systemd} an \emph{Journald}. Journald indexiert die Logs und speichert diese in komprimierter Form ab. Ersteres erlaubt das effiziente Filtern nach bestimmten Feldern, wie der Zeit.
 
 Archlinux ist eine Rolling-Release-Distribution. Das heißt, dass es keine festen
-Zeitpunkte gibt, zu denen eine neue Version veröffentlicht mit neuen Paketen
+Zeitpunkte gibt, zu denen eine neue Version mit neuen Paketen
 veröffentlicht wird. Stattdessen werden Pakete von den Maintainern
 kontinuierlich eingepflegt. Deswegen befinden sich in den offiziellen Arch Linux
 Repository in den meisten Fällen die aktuellsten Versionen der benötigten

bericht/hardware.tex

@@ -12,7 +12,7 @@ In die beiden zur Verfügung stehenden Gehäuse bauten wir jeweils zwei Mainboar
 Da nur drei ZOTAC-Boards vorhanden waren, mussten wir als vierten Compute-Node
 ein normales Intel-Mainboard (ohne nVidia-Chip) verwenden. \\
 
-Jedes Board war jeweils ausgestattet mit: %\footnote{330er Board und 1. Computenode}
+Beide Boards waren jeweils ausgestattet mit: %\footnote{330er Board und 1. Computenode}
 
 \begin{itemize}
   \item einem (bereits fest verbautem) Intel Atom 330 Prozessor

bericht/nftables/nftables-perf.tex

@@ -51,6 +51,8 @@ Zur besseren Anschaulichkeit auch in logarithmischer Ordinatenskalierung: \\
 
 Die Datenrate und die Anzahl an PPS liegen initial bei den bereits zuvor gemessenen ca. 980 MBit/s und 250000 Paketen pro Sekunde. Jedoch bricht die Leistungsfähigkeit bei beiden Firewall-Lösungen schnell erheblich ein. So kann \texttt{iptables} bei 5000 Regeln nur noch ca. 100 MBit/s bei 28000 Paketen verarbeiten, \texttt{nftables} schafft hier nur ca. 50 MBit/s bei 14000 Paketen. Im weiteren Verlauf wird jedoch in der logarithmischen Skalierung sichtbar, dass \texttt{nftables} bei mehr als ca. 25000 Regeln beginnt besser zu skalieren. Die starken Schwankungen bei vielen Regeln lassen sich eventuell auf zu kleine statisch allokierte Buffer im Kernel oder durch zunehmenden RAM-Zugriff bei vollem Cache zurückführen. RAM-Zugriff würde auch die noch stärker abnehmende PPS-Rate bei sehr vielen Regeln erklären.
 
+\pagebreak
+
 \subsubsection{Antwortzeit} Unter Verwendung der vorherigen Regeln habe ich nun die Antwortzeit gemessen. \\
 
 \includegraphics{benchmarks/nft-ipt-drop-response.pdf}
@@ -62,3 +64,5 @@ In diesem Diagramm erkennt man, dass hier \texttt{nftables}, im Gegensatz zum Pa
 \item \texttt{nftables} ist bisher sehr schlecht dokumentiert. Es ist mir bspw. nicht gelungen eine Möglichkeit zu finden, um komplette Pakete (nicht nur den Header) nach bestimmten Strings zu durchsuchen. Während dies auf Kernel-Seite durch die virtuelle Maschine eigentlich ohne Weiteres möglich sein sollte, ist diese Möglichkeit im Userspace-Tool \texttt{nft} offenbar noch nicht enthalten (oder nirgends dokumentiert).
 \item NAT-Regeln (oder generell modifizierende Regeltypen) lassen sich nicht ohne weiteres mit der Skalierung auf eine große Anzahl von Regeln benchmarken, da die Paketbearbeitung nach der ersten, den Filterkriterien entsprechenden Regel abbricht. Zukünftig sollte sich die Vereinheitlichung und die leichte Erweiterbarkeit von \texttt{nftables} gegenüber \texttt{iptables} durchsetzen können.
 \end{itemize}
+
+\pagebreak