2.8 iPerf3 – Bandbreite, Durchsatz, Jitter und Paketverlust messen

iPerf3 misst den Durchsatz zwischen den beiden iPerf3-Prozessen. Das Ergebnis ist nicht automatisch identisch mit:

• der Leitungsgeschwindigkeit des Netzwerkadapters;
• der Brutto-Datenrate eines WLANs;
• der Geschwindigkeit eines Internetanschlusses;
• der Geschwindigkeit einer Dateiübertragung;
• der Leistung einer Webanwendung;
• der Festplattenleistung;
• der nutzbaren Geschwindigkeit für jeden einzelnen Benutzer.

iPerf3 umgeht normalerweise folgende Anwendungsfaktoren

• Dateisystem;
• Festplattenzugriffe;
• SMB- oder NFS-Protokollverarbeitung;
• HTTP-Anwendung;
• Datenbankabfragen;
• Verschlüsselung einer konkreten Anwendung;
• Benutzeranmeldung;
• Virenscan einer übertragenen Datei.

Dadurch kann iPerf3 helfen, Netzwerkpfad und Anwendung voneinander zu trennen:

iPerf3 schnell + Anwendung langsam
→ Ursache wahrscheinlich nicht ausschließlich der reine Netzwerkdurchsatz

iPerf3 langsam + Anwendung langsam
→ Netzwerkpfad oder beteiligte Systeme weiter untersuchen

Nach der offiziellen ESnet-FAQ wird iPerf3 nicht offiziell unter Windows unterstützt. Es existieren Community-Builds für Windows, bei denen jedoch nicht alle Optionen funktionieren müssen.

Konsequenz für dieses Buch

• Linux, FreeBSD und macOS: iPerf3 nach offizieller ESnet-Dokumentation;
• Windows mit Community-iPerf3: Version, Quelle und Funktionsumfang ausdrücklich dokumentieren;
• Windows mit offiziell unterstützter Alternative: iPerf2 verwenden;
• iPerf2 und iPerf3 nicht als untereinander kompatibel behandeln.

Ein iPerf3-Client benötigt einen iPerf3-Server. Ein iPerf2-Client benötigt einen iPerf2-Server.

Die Version muss auf Client und Server dokumentiert werden:

Client: iPerf 3.x
Server: iPerf 3.x

Unterschiedliche iPerf3-Versionen funktionieren häufig miteinander, können aber:

• unterschiedliche Optionen unterstützen;
• Ergebnisse unterschiedlich darstellen;
• andere Standardwerte verwenden;
• Fehlerkorrekturen enthalten;
• bei neueren Funktionen inkompatibel sein.

Seit iPerf3 3.16 verwendet jeder parallele Teststream einen eigenen Thread. Ältere Versionen waren für den Testdatenverkehr grundsätzlich auf einen Thread begrenzt. Bei hohen Datenraten kann die verwendete Version deshalb das Ergebnis wesentlich beeinflussen.

Vorher prüfen:

• Darf die Verbindung ausgelastet werden?
• Gibt es produktive Sprach-, Video- oder Echtzeitanwendungen?
• Befindet sich der Testpfad hinter einer volumenbasierten Internetabrechnung?
• Gibt es QoS- oder Rate-Limit-Regeln?
• Muss eine Firewallfreigabe zeitlich begrenzt eingerichtet werden?
• Sind Client und Server leistungsfähig genug?
• Gibt es WLAN-Teilnehmer, die durch den Test beeinträchtigt werden?
• Wird der Test über VPN, Mobilfunk oder einen geteilten WAN-Link durchgeführt?
• Sind Monitoring und zuständige Administratoren informiert?

Ein unbegrenzter TCP-Test versucht, so viel Bandbreite wie möglich zu verwenden. Auch ein zehn Sekunden langer Standardtest kann deshalb andere Verbindungen beeinflussen.

Der iPerf3-Server lauscht standardmäßig auf Port 5201.

TCP-Test

Client → Server: TCP 5201

UDP-Test

Client → Server: TCP 5201 für Steuerung
Client → Server: UDP 5201 für Testdaten

Auch bei einem UDP-Test verwendet iPerf3 eine TCP-Steuerverbindung. Daher muss neben UDP 5201 auch TCP 5201 erreichbar sein.

Benutzerdefinierter Port

Server:

[TEST][DISRUPT] iperf3 -s -p 5002

Client:

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -p 5002

Für einen UDP-Test auf Port 5002 müssen gegebenenfalls beide Protokolle freigegeben sein:

TCP 5002
UDP 5002

Port vor dem Test prüfen

Windows:

[TEST] Test-NetConnection 192.0.2.20 -Port 5201

Linux:

[TEST] nc -vz 192.0.2.20 5201

macOS:

[TEST] nc -vz 192.0.2.20 5201

Ein erfolgreicher TCP-Porttest bestätigt nur die Steuerverbindung. Er bestätigt noch nicht, dass ein UDP-Testdatenstrom funktioniert.

Server auf dem Standardport 5201 starten

[TEST][DISRUPT] iperf3 -s

Server auf einem anderen Port

[TEST][DISRUPT] iperf3 -s -p 5002

Server an eine bestimmte lokale IP-Adresse binden

[TEST][DISRUPT] iperf3 -s -B 192.0.2.20

Server nur für einen Test starten und danach beenden

[TEST][DISRUPT] iperf3 -s -1

-1 beziehungsweise --one-off bedeutet:

• höchstens eine Clientverbindung bearbeiten;
• danach den Serverprozess beenden.

Das ist für kontrollierte Einzeltests häufig sicherer als ein dauerhaft laufender Server.

Einmaliger Server auf bestimmter Adresse und bestimmtem Port

[TEST][DISRUPT] iperf3 -s -1 -B 192.0.2.20 -p 5201

Ausführliche Ausgabe

[TEST][DISRUPT] iperf3 -s -V

Serverausgabe in eine Datei schreiben

[TEST][FILE][SENS][DISRUPT] iperf3 -s --logfile iperf3-server.log --forceflush

--forceflush schreibt die Intervallergebnisse zeitnah in die Logdatei, statt sie länger zu puffern.

Linux: Listener prüfen

[RO] ss -lntp | grep ':5201'

macOS: Listener prüfen

[RO][PRIV] sudo lsof -nP -iTCP:5201 -sTCP:LISTEN

Windows mit Community-Build

[RO] Get-NetTCPConnection -LocalPort 5201 -State Listen

Prozess suchen

Linux:

[RO] pgrep -a iperf3

macOS:

[RO] pgrep -fl iperf3

Windows:

[RO] Get-Process iperf3 -ErrorAction SilentlyContinue

Nach dem Test sollte ein nicht mehr benötigter iPerf3-Server beendet werden. Bei Verwendung von -1 beendet er sich nach der Clientverbindung automatisch.

Auf dem Server

[TEST][DISRUPT] iperf3 -s -1

Auf dem Client

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20

Standardmäßig:

• verwendet iPerf3 TCP;
• sendet der Client zum Server;
• dauert der Test zehn Sekunden;
• wird jede Sekunde ein Zwischenergebnis ausgegeben;
• wird Port 5201 verwendet.

Test für 30 Sekunden

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30

Ausgabe alle fünf Sekunden

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -i 5

Einheit Mbit/s erzwingen

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -f m

Serverausgabe zusätzlich am Client abrufen

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 --get-server-output

Die Serverausgabe wird nur abgerufen, wenn der Test vollständig abgeschlossen wird. Bei einem abgebrochenen Test kann sie fehlen.

Standardrichtung

Client → Server

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30

Dabei sendet der Client die Testdaten.

Umgekehrte Richtung

Server → Client

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -R

-R wird auf dem Client angegeben, obwohl anschließend der Server die Testdaten sendet.

Beide Richtungen gleichzeitig

Client ↔ Server

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 --bidir

--bidir testet beide Richtungen gleichzeitig. Das erzeugt mehr Last als zwei getrennte Einzeltests und erschwert die Interpretation.

Empfohlene Reihenfolge

1. Client zum Server testen.
2. Server zum Client mit -R testen.
3. Ergebnisse vergleichen.
4. Erst bei begründetem Bedarf --bidir verwenden.

Mögliche Ursachen für unterschiedliche Richtungen

• asymmetrisches Routing;
• unterschiedliche QoS-Regeln;
• Firewall- oder VPN-Verarbeitung;
• WLAN-Uplink und WLAN-Downlink;
• Sender- oder Empfänger-CPU;
• Netzwerkkartentreiber;
• TCP-Offloading;
• unterschiedliche Upload- und Downloadkapazität;
• unterschiedliche Paketverlustrate.

Wichtiger Unterschied

Bei TCP passt das Protokoll die Senderate unter anderem anhand von Bestätigungen, Verlust und Überlastung an. Bei UDP muss eine gewünschte Senderate festgelegt werden.

Die iPerf3-Standardrate für UDP beträgt laut aktueller Dokumentation 1 Mbit/s.

UDP-Test mit 10 Mbit/s

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 10M -t 30

UDP-Test mit 100 Mbit/s

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 100M -t 30

Umgekehrter UDP-Test

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 100M -t 30 -R

UDP-Test ohne iPerf3-interne Bitratenbegrenzung

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 0 -t 30

-b 0 deaktiviert die interne Begrenzung. Dadurch kann der Test sehr viel Verkehr erzeugen und erheblichen Paketverlust verursachen.

-b 0 sollte in produktiven Netzen nicht als erster Test verwendet werden.

Sichere Steigerung

10 Mbit/s → 25 Mbit/s → 50 Mbit/s → 100 Mbit/s

Nach jeder Stufe werden geprüft:

• Paketverlust;
• Jitter;
• Netzwerkauslastung;
• CPU-Auslastung;
• Auswirkungen auf andere Anwendungen.

Eine UDP-Zusammenfassung kann sinngemäß enthalten:

0.00-30.00 sec  350 MBytes  97.9 Mbits/sec  0.250 ms  1250/250000 (0.5%)

Jitter

Jitter beschreibt bei iPerf3 die Schwankung der Paketlaufzeit, nicht die absolute Latenz.

Daher gilt:

Niedriger Jitter ≠ automatisch niedrige Latenz

Für die absolute Laufzeit werden zusätzlich beispielsweise benötigt:

• ping;
• fping;
• pathping;
• Monitoringdaten;
• anwendungsspezifische Messungen.

Paketverlust

Verlustquote = verlorene Datagramme / erwartete Datagramme × 100

Ein Paketverlust unter hoher UDP-Last bedeutet nicht automatisch einen Defekt. Er kann auch entstehen, weil:

• die eingestellte Senderate höher als die verfügbare Bandbreite ist;
• ein QoS-Policer die Rate begrenzt;
• Empfangs- oder Sendepuffer überlaufen;
• Client oder Server CPU-limitiert ist;
• WLAN-Kollisionen oder Funkstörungen auftreten;
• die Firewall den Datenstrom nicht schnell genug verarbeitet.

Der Test sollte deshalb mit mehreren kontrollierten Datenraten wiederholt werden.

Beispiel für einen freigegebenen 100-Mbit/s-Pfad:

Stufe 1

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 10M -t 30

Stufe 2

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 25M -t 30

Stufe 3

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 50M -t 30

Stufe 4

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 90M -t 30

Dokumentation

Die Werte in dieser Tabelle sind lediglich ein Rechen- und Dokumentationsbeispiel und keine allgemein gültigen Grenzwerte.

Die sinnvoll nutzbare Rate liegt unterhalb des Punktes, an dem Verlust und Jitter deutlich ansteigen.

Vier parallele TCP-Streams

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -P 4 -t 30

Acht parallele Streams

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -P 8 -t 30

Umgekehrte Richtung mit vier Streams

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -P 4 -t 30 -R

Seit iPerf3 3.16 verwendet jeder Teststream einen eigenen Thread. Dadurch können mehrere Streams mehrere CPU-Kerne nutzen.

Warum mehrere Streams mehr Durchsatz erreichen können

• einzelne TCP-Verbindung ist durch Latenz und Empfangsfenster begrenzt;
• einzelne CPU oder ein einzelner Stream erreicht seine Grenze;
• Paketverlust reduziert das Congestion Window einer einzelnen Verbindung;
• Lastverteilung behandelt mehrere Flows unterschiedlich;
• mehrere Warteschlangen einer Netzwerkkarte werden verwendet.

Wichtige Interpretation

1 Stream langsam
4 Streams schnell

bedeutet nicht automatisch, dass die Verbindung fehlerfrei ist. Eine einzelne Anwendung verwendet möglicherweise nur eine TCP-Verbindung und erreicht dann weiterhin den niedrigeren Wert.

Empfohlener Vergleich

Testdauer

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 60

-t 60 testet 60 Sekunden.

Bestimmte Datenmenge übertragen

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -n 1G

Bestimmte Anzahl Blöcke übertragen

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -k 10000

Die Optionen -t, -n und -k schließen sich gegenseitig aus. Pro Test darf nur eine davon zur Begrenzung verwendet werden.

Erste fünf Sekunden nicht in die Statistik aufnehmen

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -O 5

-O 5 führt zunächst fünf Sekunden Warmlauf durch und lässt diese Messwerte aus der abschließenden Teststatistik heraus.

Das hilft, den Einfluss des TCP Slow Start auf die Zusammenfassung zu reduzieren.

Sinnvoller stabiler TCP-Test

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -O 5 -i 5

Die gesamte Verbindung besteht dabei aus Warmlaufphase und ausgewerteter Testphase. Die genaue Laufzeit ist daher länger als der reine Auswertungszeitraum.

Ein System kann mehrere Netzwerkschnittstellen und IP-Adressen besitzen:

• Ethernet;
• WLAN;
• VPN;
• Managementnetz;
• Produktionsnetz;
• IPv4 und IPv6.

Client an eine lokale IP-Adresse binden

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -B 192.0.2.10

Server an eine lokale IP-Adresse binden

[TEST][DISRUPT] iperf3 -s -B 192.0.2.20

Linux: an ein Interface binden, sofern unterstützt

[TEST][PRIV][DISRUPT][SENS] sudo iperf3 -c 192.0.2.20 --bind-dev eth0

--bind-dev ist nicht auf allen Plattformen verfügbar und kann erhöhte Rechte erfordern.

Vorher prüfen

Windows:

[RO] Get-NetIPConfiguration

Linux:

[RO] ip address show

macOS:

[RO] ifconfig

Die Quelladresse beeinflusst:

• Routing;
• Firewallregeln;
• VPN-Auswahl;
• QoS;
• NAT;
• Rückweg;
• Aussagekraft des Messergebnisses.

IPv4 erzwingen

[TEST][DISRUPT][SENS] iperf3 -4 -c 192.0.2.20

IPv6 erzwingen

[TEST][DISRUPT][SENS] iperf3 -6 -c 2001:db8::20

IPv6-Reversetest

[TEST][DISRUPT][SENS] iperf3 -6 -c 2001:db8::20 -R

IPv6-Link-Local-Adresse

Bei einer Link-Local-Adresse muss die Schnittstelle beziehungsweise Zone angegeben werden:

[TEST][DISRUPT][SENS] iperf3 -6 -c fe80::20%en0

Der genaue Schnittstellenname ist betriebssystemspezifisch.

Vergleich

JSON im Terminal ausgeben

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -J

Linux und macOS: JSON in Datei schreiben

[TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 -J > iperf3-result.json

PowerShell mit Community-iPerf3

[TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 -J | Out-File -Encoding utf8 iperf3-result.json

Direkte Logdatei

[TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 --logfile iperf3-result.log

Zeitstempel hinzufügen

[TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 --timestamps --logfile iperf3-result.log

Zeilenweise JSON-Objekte während des Tests

[TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 --json-stream > iperf3-stream.jsonl

--json-stream ist eine neuere Funktion. Vor Verwendung muss geprüft werden, ob die installierte Version sie unterstützt.

Für eine vollständige Dokumentation festhalten

• Client-IP;
• Server-IP;
• Netzwerkpfad;
• iPerf3-Versionen;
• Befehl;
• Datum und Uhrzeit;
• Testdauer;
• Protokoll;
• Richtung;
• Anzahl paralleler Streams;
• TCP- oder UDP-Rate;
• CPU-Auslastung;
• Interface-Zähler;
• Ergebnisdatei.

Eine TCP-Ausgabe enthält am Ende typischerweise eine Sender- und eine Empfängerzeile:

[SUM] 0.00-30.00 sec  3.20 GBytes  916 Mbits/sec  sender
[SUM] 0.00-30.00 sec  3.19 GBytes  913 Mbits/sec  receiver

Sender und Receiver

Die Werte können geringfügig voneinander abweichen, beispielsweise durch:

• noch unterwegs befindliche Daten;
• unterschiedliche Messzeitpunkte;
• kurzen Test;
• Paketverlust;
• Abbruch der Steuerverbindung.

Bei sehr kurzen Tests kann die Differenz stärker auffallen. Die ESnet-FAQ weist darauf hin, dass Testdaten noch unterwegs sein können, wenn die Steuerverbindung bereits das Testende verarbeitet.

Retransmissions

Viele Wiederholungsübertragungen können hinweisen auf:

• Paketverlust;
• Überlastung;
• fehlerhafte Leitung;
• WLAN-Störungen;
• überfüllte Warteschlangen;
• MTU- oder Offloading-Probleme.

Sie beweisen allein jedoch noch keine bestimmte Ursache.

Schwankender Durchsatz

Mögliche Ursachen:

• konkurrierender Datenverkehr;
• WLAN-Funkbedingungen;
• TCP Congestion Control;
• CPU-Auslastung;
• Firewall- oder VPN-Verarbeitung;
• thermische Drosselung;
• Paketverlust;
• Load Balancing;
• dynamische QoS-Regeln.

1. Normalrichtung

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30

2. Gegenrichtung

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -R

3. Einzelstream

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -P 1 -t 30

4. Vier Streams

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -P 4 -t 30

5. CPU-Auslastung parallel beobachten

Linux:

[RO] top

macOS:

[RO] top

Windows:

[RO] Get-Counter '\Processor(_Total)\% Processor Time'

Interpretationsbeispiele

Windows

[RO] Get-NetAdapter

[RO] Get-NetAdapterStatistics

[RO] Get-NetAdapter | Select-Object Name, Status, LinkSpeed

Linux

[RO] ip -s link show

[RO] ethtool eth0

[RO][PRIV] sudo ethtool -S eth0

macOS

[RO] ifconfig en0

[RO] netstat -ib

Vor und nach dem iPerf3-Test vergleichen

Zu prüfen sind unter anderem:

• Linkgeschwindigkeit;
• empfangene und gesendete Byte;
• RX- und TX-Fehler;
• Drops;
• Kollisionen, sofern relevant;
• Interface-Resets;
• Duplexmodus bei Ethernet;
• WLAN-Signal und Übertragungsrate;
• CPU-Auslastung.

Ein iPerf3-Ergebnis ohne Interface- und Systemauslastung zeigt nur den gemessenen End-to-End-Durchsatz, aber nicht automatisch die Engpassstelle.

TCP Maximum Segment Size setzen

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -M 1460

-M setzt die gewünschte TCP-MSS. Der tatsächlich verwendete Wert kann durch Betriebssystem und Netzwerkpfad beeinflusst werden.

Für Ethernet mit einer MTU von 1500 Byte ergibt sich bei IPv4 ohne zusätzliche Optionen häufig:

1500 Byte MTU
- 20 Byte IPv4-Header
- 20 Byte TCP-Header
= 1460 Byte TCP-MSS

Bei IPv6 sind die Basisheader größer:

1500 Byte MTU
- 40 Byte IPv6-Header
- 20 Byte TCP-Header
= 1440 Byte TCP-MSS

Zusätzliche Header, TCP-Optionen, VLAN, VPN oder Tunnel können die nutzbare Größe beeinflussen.

iPerf3-Puffer- beziehungsweise Blocklänge

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -l 512

-l bestimmt die Länge des von iPerf3 gelesenen oder geschriebenen Puffers. Sie ist nicht identisch mit der Ethernet-Framegröße.

UDP mit bestimmter Datagrammlänge

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 10M -l 1200

IPv4-UDP mit gesetztem Don't-Fragment-Bit

[TEST][DISRUPT][SENS] iperf3 -4 -c 192.0.2.20 -u -b 10M -l 1400 --dont-fragment

--dont-fragment gilt nach der offiziellen Dokumentation nur für UDP über IPv4.

Größenoptionen sollten nur gezielt verändert werden. Ungeeignete Werte können Fragmentierung, Verluste oder irreführende Ergebnisse verursachen.

Nach der offiziellen ESnet-FAQ kann ein fast vollständig einbrechender TCP-Durchsatz unter anderem mit fehlerhaftem TCP-Offloading zusammenhängen.

Mögliche beteiligte Funktionen:

• TCP Segmentation Offload, TSO;
• Large Send Offload, LSO;
• Generic Segmentation Offload, GSO;
• Generic Receive Offload, GRO;
• Large Receive Offload, LRO.

Diagnosevergleich

Normalrichtung

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30

Reverse-Richtung

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -R

Kleinere Schreibgröße

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -l 512

MSS testweise begrenzen

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -M 1460

Zusätzliche Prüfung

• Paketmitschnitt mit Wireshark oder tcpdump;
• ICMP-Fragmentation-Needed-Nachrichten;
• Wiederholungsübertragungen;
• Interface-Fehler;
• MTU des VPN- oder Tunnelpfads;
• Treiber- und Firmwarestand.

Das Deaktivieren von Offloading ist eine Systemänderung und kann die Leistung beeinflussen. Es sollte erst nach dokumentierter Diagnose, Freigabe und mit Rückfallplan erfolgen.

Ein geeigneter WLAN-Testaufbau ist:

WLAN-Client
    ↓ Funkstrecke
Access Point
    ↓ Ethernet
Kabelgebundener iPerf3-Server

Der Server sollte möglichst per Ethernet angebunden sein. Sind Client und Server beide im WLAN, teilen sie sich möglicherweise dieselbe Funkzeit. Das Ergebnis enthält dann zwei Funkübertragungen und ist schwerer zu interpretieren.

Empfohlene Tests

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -R

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 10M -t 30

Die UDP-Rate wird anschließend vorsichtig erhöht.

Zusätzlich dokumentieren

• Frequenzband;
• Kanal;
• Kanalbreite;
• Signalstärke;
• Noise Floor, sofern verfügbar;
• PHY-Linkrate;
• Abstand zum Access Point;
• Anzahl aktiver Clients;
• Roaming;
• Energiesparmodus;
• verwendeter Access Point.

Wichtiger Unterschied

WLAN-Linkrate ≠ nutzbarer TCP-Durchsatz

Die angezeigte PHY-Rate enthält Protokoll-, Funk-, Bestätigungs- und Verwaltungsanteile. Der tatsächlich nutzbare TCP-Durchsatz ist daher niedriger.

Messung ohne VPN

Client → lokaler iPerf3-Server

Messung durch VPN

Client → VPN-Tunnel → entfernter iPerf3-Server

Normalrichtung

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30

Reverse-Richtung

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30 -R

UDP mit kontrollierter Rate

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -u -b 20M -t 30

Mögliche VPN-Engpässe

• CPU des VPN-Gateways;
• Verschlüsselungsleistung;
• MTU und MSS;
• Paketfragmentierung;
• Internet-Uplink;
• asymmetrische Bandbreite;
• Paketverlust;
• hohe Laufzeit;
• Single-Stream-Limit;
• QoS oder Traffic Shaping;
• Cloud-Gateway-Größe;
• NAT- oder Firewall-Verarbeitung.

Vergleichstabelle

Diese Zahlen sind nur ein Dokumentationsbeispiel. Sie stellen keine allgemeinen Sollwerte dar.

Netzwerktest

[TEST][DISRUPT][SENS] iperf3 -c 192.0.2.20 -t 30

Anschließend reale Dateiübertragung prüfen

Beispielsweise:

• SMB;
• NFS;
• SFTP;
• HTTPS;
• Backupsoftware.

Interpretation

iPerf3 bietet außerdem -F, um eine Datei als Datenquelle oder -senke zu verwenden:

[TEST][FILE][DISRUPT][SENS] iperf3 -c 192.0.2.20 -F testfile.bin

Diese Funktion bezieht Speicherzugriffe in die Messung ein.

-F macht iPerf3 nicht zu einem zuverlässigen Dateiübertragungsprogramm. Die empfangene Datei kann sich in Länge, Eigenschaften oder Inhalt vom Original unterscheiden.

Vorbereitung

1. Fehlerbild und erwarteten Durchsatz dokumentieren.
2. Client, Server und Netzwerkpfad festlegen.
3. Testgenehmigung und Wartungszeitraum prüfen.
4. Maximale Testdauer und Datenrate festlegen.
5. iPerf3-Versionen auf beiden Endpunkten dokumentieren.
6. CPU-, Interface- und Monitoringansichten vorbereiten.
7. Firewallfreigabe für TCP und gegebenenfalls UDP prüfen.

Server

8. Server möglichst kabelgebunden und leistungsfähig auswählen.
9. Server an die richtige Adresse binden.
10. Für Einzeltests möglichst -1 verwenden.
11. Listener auf Port 5201 kontrollieren.

Basistest

12. TCP-Einzelstream für 30 Sekunden durchführen.
13. TCP-Reverse-Test durchführen.
14. Sender- und Receiverwerte dokumentieren.
15. CPU- und Interface-Zähler prüfen.

Vertiefung

16. Vier parallele Streams testen.
17. Ergebnis mit Einzelstream vergleichen.
18. UDP bei niedriger Rate beginnen.
19. Rate schrittweise erhöhen.
20. Jitter und Paketverlust dokumentieren.
21. IPv4 und IPv6 bei Bedarf getrennt testen.
22. WLAN-, VPN- oder VLAN-Pfade separat vergleichen.

Analyse

23. Langsamen Pfad mit Ping, Traceroute und Paketmitschnitt untersuchen.
24. Firewall-, Switch- und VPN-Monitoring vergleichen.
25. MTU, MSS und Offloading nur bei konkreten Hinweisen untersuchen.
26. iPerf3-Ergebnis mit realer Anwendung vergleichen.

Abschluss

27. Testbefehle und Ergebnisse speichern.
28. Temporäre Firewallfreigaben zurücknehmen.
29. Nicht mehr benötigten Serverprozess beenden.
30. Beobachtung, Hypothese, Änderung und Nachtest dokumentieren.