Mic92/ltcp
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

nftables: Rechtschreibfehler korregiert

Browse Source
This commit is contained in:
Jörg Thalheim 2014-03-09 18:47:36 +01:00
parent b055f49ec2
commit fe77f6a65d
2 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
bericht/nftables/nftables-perf.tex
View File

@ -41,7 +41,7 @@ Beim Empfänger geschieht dieser Einbrauch schon bei ca. 450 Byte Frame-Größe.
Um eine größtmögliche Auslastung des Gigabit-Netzwerkes zu ermöglichen und gleichzeitig die maximale Anzahl an PPS zu erhalten, habe ich also für die folgenden Benchmarks die Ethernet Frame-Größe auf 450 festgesetzt.
\paragraph{Anfängliche Probleme} Anfangs habe ich auf dem Empfänger keine »Anwendung« laufen lassen, die die Pakete des Senders entgegennimmt. Deshalb musste der Kernel zusätzliche ein ICMP-Paket mit »Connection Refused«-Flag an den Sender zurückschicken und daraufhin weitere Fehlerbehandlungen durchführen. Auf diese Weise habe ich am Empfänger zunächst nur ca. 110000 PPS empfangen können. Als Lösungsansatz habe ich dann \texttt{netcat} auf dem Port am Empfänger laufen lassen und die Daten nach \texttt{/dev/null} umgeleitet. Damit kamen keine Fehler mehr zustande und es konnten ca. 150000 PPS empfangen werden. Dies liegt jedoch immer noch weit unter den am Sender losgeschickten 450000 PPS und ist damit zu erklären, dass es für jedes Paket zu einem Kontex-Switch vom Kernel zu \texttt{netcat} kam und deshalb wieder die Bearbeitungszeit pro Paket stieg. \\
\paragraph{Anfängliche Probleme} Anfangs habe ich auf dem Empfänger keine »Anwendung« laufen lassen, die die Pakete des Senders entgegennimmt. Deshalb musste der Kernel zusätzliche ein ICMP-Paket mit »Connection Refused«-Flag an den Sender zurückschicken und daraufhin weitere Fehlerbehandlungen durchführen. Auf diese Weise habe ich am Empfänger zunächst nur ca. 110000 PPS empfangen können. Als Lösungsansatz habe ich dann \texttt{netcat} auf dem Port am Empfänger laufen lassen und die Daten nach \texttt{/dev/null} umgeleitet. Damit kamen keine Fehler mehr zustande und es konnten ca. 150000 PPS empfangen werden. Dies liegt jedoch immer noch weit unter den am Sender losgeschickten 450000 PPS und ist damit zu erklären, dass es für jedes Paket zu einem Kontext-Switch vom Kernel zu \texttt{netcat} kam und deshalb wieder die Bearbeitungszeit pro Paket stieg. \\
Letztendlich habe ich dazu entschieden, auf der Empfängerseite mit \texttt{iptables} die Pakete, die auf dem entsprechenden Port angekommen, direkt zu droppen. Damit konnten nun die zuvor erwähnten ca. 250000 PPS empfangen werden.
@ -71,4 +71,4 @@ In diesem Diagramm erkennt man, dass hier \texttt{nftables}, im Gegensatz zum Pa
\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.
\end{itemize}
\pagebreak
\pagebreak

2
chef

@ -1 +1 @@
Subproject commit d679c3fc7134aa3034441c532372ecfe015956b9
Subproject commit fdb6fdcee26bbd3f67ffbd24ddb27fe7a40bb06b