Paketschleudern

Benchmarks fĂĽr individuelle Anwendungen wie Datenbanken, File- oder Webserver sind sinnvoll, verraten jedoch nur die halbe Wahrheit. Bevor man ihre Ergebnisse interpretiert, sollte man das Netz selbst und die beteiligten Rechner genauer unter die Lupe nehmen.

vorlesen Druckansicht 4 Kommentare lesen
Lesezeit: 5 Min.
Von
  • Michael Riepe

Wer lange genug im Netz unterwegs ist, erlebt irgendwann den Einzug neuer, schnellerer Übertragungstechnik ins LAN, WLAN oder WAN. Nicht selten fragt man sich jedoch hinterher, wo das versprochene Mehr an Leistung geblieben ist. Ein Umstieg von Fast- auf Gigabit-Ethernet etwa verzehnfacht die Übertragungskapazität, doch spürbar ist das nur selten, und selbst messtechnisch bleibt vom Faktor Zehn manchmal nur wenig übrig.

Mitunter ist daran nicht das Netz schuld, sondern die beteiligten Rechner. Ein schwachbrüstiger Prozessor kann mit der Flut ein- oder ausgehender Ethernet-Pakete schlicht überfordert sein – vor allem, wenn der Netzwerktreiber die CPU bei jeder Kleinigkeit aus dem Schlaf reißt oder von ihren eigentlichen Aufgaben abhält, etwa dem Ausliefern von Dateien, Webseiten und E-Mails. Selbst der Einsatz von Multi-Core-Systemen schafft nur bedingt Abhilfe: Ist der für die Netzkommunikation zuständige Kern voll ausgelastet, lässt sich die Leistung nicht weiter steigern. Vor allem kleine, energiesparende Server und Embedded-Systeme haben mit solchen Schwierigkeiten zu kämpfen.

Will man der Ursache auf den Grund gehen und sicherstellen, dass das Netz einwandfrei funktioniert, empfiehlt sich ein Low-Level Benchmark, der das Netz auf TCP/IP-Ebene vermisst. Dafür bietet sich zum Beispiel iperf an. Der Quelltext des Programms lässt sich auf gängigen Unix- und Linux-Systemen übersetzen, mit der Cygwin-Umgebung auch unter Windows.

Für eine Messung muss das Programm auf beiden Rechnern installiert sein. Auf einem agiert es mit der Option –s als Server, auf dem anderen kann der Nutzer mit –c <serveradresse> die Verbindung herstellen. Fügt man beim Server die Option –D hinzu, läuft er als Daemon beziehungsweise Windows-Service im Hintergrund. Meldungen sollte man dann mit –o <dateiname> in eine Datei umleiten. Mit –p <port> und –B <adresse> lässt sich der Server an einen bestimmten Port oder eine bestimmte Adresse binden. Wer Messungen mit IPv6 durchführen will, muss beiden Instanzen die Option –V mit auf den Weg geben.

In der Standardeinstellung misst iperf den TCP-Durchsatz vom Client zum Server. Für eine Messung in der anderen Richtung müssen die Rechner die Rollen tauschen. Der Nutzer kann jedoch auch mit der Option –d eine gleichzeitige Messung in beiden Richtungen durchführen. Mit –P <anzahl> lassen sich auf dem Client mehrere Verbindungen parallel öffnen. iperf zeigt dann sowohl die Messergebnisse für die einzelnen Verbindungen an als auch das Gesamtergebnis.

Für Messungen mit UDP muss der Nutzer Client und Server mit der Option –u starten. Im LAN oder WLAN sollte er außerdem beim Aufruf des Clients mit –b <bit/s> die Sendegeschwindigkeit erhöhen – voreingestellt ist 1 MBit/s. Mit der nachgestellten Einheit K oder M lassen sich hohe Werte bequem eingeben, etwa 1000M für Gigabit-Ethernet. Als Ergebnis zeigt iperf nicht nur den ermittelten Durchsatz an, sondern auch den „Jitter“ – Variationen der Paketlaufzeit, die vor allem bei Multimedia-Übertragungen eine Rolle spielen –, Zahl und Prozentsatz der verloren gegangenen (UDP-)Pakete sowie die Zahl der Pakete, die in der falschen Reihenfolge eingetroffen sind. Letzteres kann unter anderem passieren, wenn Pakete unterschiedliche Wege zum Ziel nehmen.

Fallen die Messergebnisse nicht zufriedenstellend aus, kann der Nutzer versuchen, die Übertragungsparameter zu tunen. Bei TCP etwa lassen sich Window Size und Maximum Segment Size (MSS) einstellen; außerdem kann man mit –N den Nagle-Algorithmus abstellen, der aus Effizienzgründen versucht, Daten zusammenzufassen, und deshalb sendefähige Daten kurzzeitig zurückhält. Bei UDP lässt sich die Länge der Datagramme variieren, im Multicast-Betrieb außerdem die Time To Live (TTL) der IP-Pakete.

netperf arbeitet ähnlich wie iperf, verwendet jedoch einen separaten Server namens netserver. Der läuft im Hintergrund und überträgt etwaige Messergebnisse an den Client. Das Programm kann TCP-, UDP- und SCTP-Durchsatz (Stream Control Transmission Protocol) messen und dabei nicht nur Berkeley-Sockets als Schnittstelle verwenden, sondern – falls vorhanden – auch die weniger gängigen Interfaces XTI (X/Open Transport Interface) und DLPI (Data Link Provider Interface).

Außerdem bietet das Programm die Möglichkeit, Request/Response-Tests durchzuführen, die für viele Netzdienste charakteristisch sind. Auch die Zeit für den Auf- und Abbau einer TCP-Verbindung (Connect/Close) lässt sich messen. Nebenbei kann netperf auf beiden Rechnern die CPU-Auslastung feststellen und zusammen mit dem Messergebnis anzeigen, sodass sich der Einsatz separater Tools wie top erübrigt. Wer wirklich Nutzen aus den zahlreichen Möglichkeiten des Programms ziehen will, wird jedoch ums Studium des online verfügbaren Handbuchs nicht herumkommen.

Alle Links: www.ix.de/ix1111163 (mr)