So verwenden Sie NTTTCP unter Windows: Tests, Befehle und Optimierungen

Wenn Sie die tatsächliche Leistung Ihres Netzwerks unter Windows (und auch unter Linux) messen müssen, ohne die Lagerung oder die CPU-Bedingungen, die SieNTTTCP ist eines der zuverlässigsten Dienstprogramme zum Testen von Bandbreite und praktischer Latenz. Dieses Microsoft-Tool konzentriert die Last auf die Netzwerkschicht und hilft Ihnen, Engpässe, Konfigurationsprobleme und physische Verbindungslimits zu erkennen.

In diesem Artikel haben wir alle wichtigen Informationen zur Verwendung von NTTTCP gesammelt und in einem einzigen Leitfaden neu organisiert.: Voraussetzungen, Installation unter Windows und Linux, Befehle Schlüssel, empfohlene Testparameter (wie z. B. Festlegen einer gemeinsamen Dauer mit -t), Ausführung in virtuelle Maschinen und in Amazon EC2: TCP-Fensteroptimierung, Leseergebnisse (MB/s, Mbit/s, Zyklen/Byte, DPC, Interrupts) und die Interpretation von erneuten Übertragungen und Fehlern. Sie erfahren auch, wann es sinnvoll ist, iperf oder andere Tools wie ctsTraffic zu verwenden.

Was ist NTTTCP und warum wird es verwendet?

NTTTCP (NT Test TCP) ist ein kostenloses Dienstprogramm von Microsoft zum Messen der Netzwerkleistung., sowohl auf physischen als auch auf virtuellen Maschinen, mit direktem Fokus auf dem TCP/UDP-Stack. Der Vorteil besteht darin, dass der Einfluss anderer Subsysteme (Festplatten, Back-End-Dienste usw.) minimiert wird, sodass der Test das tatsächliche Verhalten der Verbindung widerspiegelt.

Es ist für Windows verfügbar und es gibt eine kompatible Implementierung für Linux (ntttcp-for-linux)., sodass Sie homogene Tests an verschiedenen OSDies ist besonders in Cloud-Umgebungen wie Azure oder AWS nützlich, wo die Konfiguration von Instanzen, Netzwerkwarteschlangen und Treibern erhebliche Auswirkungen hat.

Mit NTTTCP können Sie die Anzahl der Threads, die CPU-Zuordnung, die Ports und verschiedene Timer steuern, zusätzlich zur Aktivierung bestimmter Modi für gemischte Tests zwischen Windows und Linux. Auf diese Weise können Sie realistische Lasten simulieren, mehrere NIC-Warteschlangen sättigen und die Auswirkungen auf Interrupts, DPC, Zyklen/Byte und CPU-Auslastung beobachten.

Anforderungen und Umgebungsbeispiel

Stellen Sie zunächst sicher, dass Sie über zwei Computer oder VMs mit Verbindung zwischen ihnen verfügen. (Routen, Sicherheits-/Netzwerkgruppen, Firewall) und Berechtigungen zum Installieren/Ausführen von Tools. Es ist ratsam, unter Windows über Administratorrechte und unter Linux über Sudo zu verfügen.

Beispiel für im gesamten Text verwendete Parameter (Sie können sie anpassen):

Parameter	Wert
Empfänger-IP	10.0.0.5
CPU-Kerne pro VM	2

In 1-GbE-Netzwerken zeigt eine anhaltende Übertragungsrate von etwa 112 MB/s normalerweise an, dass Sie sich nahe am theoretischen Maximum befinden., vorausgesetzt, der TCP-Stack ist gut abgestimmt und es treten keine Verluste auf. Bei Verbindungen mit 10 GbE oder höher ist es unerlässlich, das TCP-Fenster zu überprüfen und in einigen Fällen Jumbo-Frames konsequent zu aktivieren.

Installation und Vorbereitung unter Windows und Linux

Windows: Laden Sie die neueste Version von NTTTCP aus dem offiziellen Microsoft-Repository (GitHub) herunter, entpacken Sie das Paket und öffnen Sie eine Konsole mit Administratorrechten. Dann Wechseln Sie in das Verzeichnis, das Ihrer Systemarchitektur entspricht (z. B. x64), um das Dienstprogramm auszuführen.

Linux: Um ntttcp-for-linux zu verwenden, installieren Sie zuerst die Abhängigkeiten und kompilieren Sie es. Unter Ubuntu müssen Sie nur bauwesentlich y git; auf SUSE, mit Git-Kern, gcc y um. Klonen und kompilieren Sie dann das Projekt.

Vorbereitungsbefehle in Ubuntu (passen Sie sie an, wenn Ihre Distribution anders ist):

Läuft auf der Linux-VM und überprüfen Sie, dass keine Fehler vorliegen:
sudo apt-get update && sudo apt-get -y install build-essential git

Vorbereitungsbefehle in SUSE (installiert Pakete und löst Abhängigkeiten auf, falls diese auftreten):
sudo zypper in -y git-core gcc make

Klonen und Kompilieren von ntttcp-for-linux (von jeder kompatiblen Distribution):
git clone https://github.com/Microsoft/ntttcp-for-linux && cd ntttcp-for-linux/src && sudo make && sudo make install

So führen Sie Benchmarks mit NTTTCP unter Windows aus

Die übliche Empfehlung besteht darin, sowohl am Sender als auch am Empfänger eine Dauer von 300 Sekunden (-t 300) einzustellen. um den Durchsatz zu stabilisieren und CPU- und Interrupt-Metriken über einen längeren Zeitraum zu überwachen. Beide Seiten sollten denselben -t-Wert verwenden.

Führen Sie auf dem Empfänger (Windows) aus Ersetzen Sie die Anzahl der Kerne und die Ziel-IP durch Ihre:
ntttcp -r -m [num_de_nucleos x 2],*,10.0.0.5 -t 300

Beispielempfänger mit 2 Adern (4 Drähte) unter Verwendung der IP aus dem Beispiel:
ntttcp -r -m 4,*,10.0.0.5 -t 300

Auf dem Sender (Windows) ist der Befehl analog aber ändern Sie -r in -s, um anzuzeigen, dass es sendet:
ntttcp -s -m [num_de_nucleos x 2],*,10.0.0.5 -t 300

Beispiel eines 4-Leiter-Transmitters zeigt auf den Empfänger 10.0.0.5:
ntttcp -s -m 4,*,10.0.0.5 -t 300

Was ist beim Ausstieg zu beachten?: Thread-Durchsatz, Gesamt-MB/s, durchschnittliche Frame-Größe, Puffer/s, Zyklen/Byte, DPC, Interrupts, gesendete/empfangene Pakete, erneute Übertragungen, Fehler und %CPU. Anhand dieser Felder können Sie erkennen, ob die Bandbreite durch den TCP-Stack, die Netzwerkkarte oder die CPU begrenzt ist.

So führen Sie NTTTCP unter Linux aus

Unter Linux ist die Syntax praktisch identisch.. Denken Sie daran, dass die Standarddauer normalerweise 60 Sekunden beträgt, wenn Sie -t nicht angeben, was für eine stabile Messung möglicherweise nicht ausreicht.

Empfänger (Linux) mit 4 Threads und 5 Minuten Dauer:
ntttcp -r -m 4,*,10.0.0.5 -t 300

Sender (Linux) auf denselben Empfänger ausgerichtet und für dieselbe Dauer:
ntttcp -s -m 4,*,10.0.0.5 -t 300

Die typische Ausgabe unter Linux fasst die erstellten Verbindungen, die Dauer, die Gesamtbytes, den Durchsatz (Mbit/s), die erneuten Übertragungen (Retrans-Segmente) und die CPU-Auslastung zusammen.Darüber hinaus werden Ihnen Indikatoren wie Zyklen/Byte oder der Prozentsatz der CPU-Auslastung angezeigt, die für das Verständnis der Stapeleffizienz hilfreich sind.

Gemischte Tests zwischen Windows und Linux

Aktivieren Sie zum Testen zwischen Windows und Linux den No-Sync-Modus. Um interne Handshake-Probleme zu vermeiden: Fügen Sie in Windows hinzu -ns und in Linux fügt es hinzu -NDies vereinfacht die Koordination zwischen Endpunkten und verhindert Blockaden aufgrund von Implementierungsunterschieden.

Relevante Netzwerkeinstellungen: TCP/IP-Fenstergröße

Bei 1GbE-Verbindungen mit geringer Latenz bietet das Standard-TCP-Fenster (~64 KB mit SO_RCVBUF in NTttcp) normalerweise eine gute Leistung.Dadurch wird vermieden, dass Stapelparameter für einfache LAN-Fälle geändert werden müssen.

Bei Netzwerken mit hoher Latenz oder bei 10 GbE und höher kann das Standardfenster zu kurz sein., wodurch der effektive Durchsatz reduziert wird. Hier empfiehlt es sich, die TCP-Fenstergröße anzupassen, um ein höheres Produkt aus Bandbreite und Verzögerung zu unterstützen.

NTTTCP ermöglicht es Ihnen, das Fenster mit -rb statisch zu fixieren, wodurch die automatische Stapeloptimierung deaktiviert wird. Verwenden Sie dies nur, wenn Sie die Auswirkungen vollständig verstehen, da das Erzwingen eines großen Fensters in ungeeigneten Szenarien die Leistung beeinträchtigen kann.

Als allgemeine Richtlinie gilt: Beginnen Sie mit den Standardeinstellungen und erhöhen Sie diese nur, wenn es Ihr Fall erfordert. (hohe Latenz, WAN, Multi-Hop). Ergänzen Sie diese Tests mit den Netzwerk-Tuning-Anleitungen des Betriebssystems für dauerhafte Anpassungen.

NTTTCP auf Amazon EC2 (Windows)-Instances

Wenn Sie mit AWS arbeiten, können Sie NTTTCP verwenden, um optimale Instanztypen, -größen und -konfigurationen auszuwählen.. Die Tests helfen Ihnen, die tatsächliche Leistung mit der veröffentlichten Leistung von AWS für jede EC2-Familie zu vergleichen.

Empfohlene Voraussetzungen für EC2 (Windows):

• Booten Sie zwei Windows-Instanzen für Netzwerktests.
• Stellen Sie sicher, dass sie Enhanced Networking unterstützen (aktualisierte Treiber und unterstützter Instanztyp).
• Passen Sie die MTU an, wenn sie sich nicht in derselben Platzierungsgruppe befinden oder keine Jumbo-Frames verwenden, wobei die End-to-End-Konsistenz gewahrt bleibt.
• Überprüfen der Konnektivität (RDP, ggf. Ping, Routen und Sicherheit).

Installation in beiden Fällen: Laden Sie die neueste Version von NTttcp von Microsoft herunter, entpacken Sie sie in einen Ordner und öffnen Sie sie. CMD als Administrator. Geben Sie vor dem Ausführen das Verzeichnis ein, das der Architektur Ihrer Instanz entspricht.

Häfen und Sicherheit: Standardmäßig verwendet NTTTCP Port 5001 für TCP und UDP, Sie können dies jedoch ändern mit -p. versichert dass Sicherheitsgruppen und Windows-Firewall erlauben Datenverkehr erforderlich und Verbindungen zu ntttcp.exe (eingehend und ausgehend).

TCP-Leistungstest auf EC2 (Empfänger): Initialisiert den Listener vom gewählten Port. Beispiel mit zwei Threads auf den Ports 80–81, die den CPUs 0 und 1 zugewiesen sind:
ntttcp -r -p 80 -a 6 -t 60 -cd 5 -wu 5 -v -xml c:\bench.xml -m 1,0,192.168.1.4 1,1,192.168.1.4

Bedeutung der obigen Parameter (Empfänger):

• -r: Empfangsmodus.
• -p 80: Basisport des ersten Threads (inkrementiert durch zusätzlichen Thread).
• und 6: Asynchrone E/A mit 6 überlappenden Empfangspuffern pro Thread.
• -t 60: Testdauer in Sekunden.
• -CD 5: 5 Sekunden Abkühlung zur Stabilisierung am Ende des Tests.
• -wu 5: 5 Sekunden Aufwärmen, um den Start zu stabilisieren.
• -v: detaillierte Ausgabe.
• -xml c:\bench.xml: speichert Ergebnisse im XML-Format im angegebenen Pfad (standardmäßig xml.txt).
• -m: Sitzungszuordnung (Threads, CPU-ID, Empfänger-IP), Sitzungen durch Leerzeichen trennen.

TCP-Leistungstest auf EC2 (Sender): Verwenden Sie in beiden Befehlen dieselben Parameter, wechseln Sie in den Sendemodus und zielen Sie auf die IP des Empfängers ab:
ntttcp -s -p 80 -a -t 60 -cd 5 -wu 5 -m 1,0,192.168.1.4 1,1,192.168.1.4

Bedeutung der einzelnen Parameter (Emittent):

• -s: Versandart.
• -p 80: Basisport pro Thread (Inkremente pro Thread).
• -a: überlappende Sendepuffer pro Thread (Standard 2, geben Sie diesen Wert an, wenn Sie einen anderen Wert wünschen).
• -t, -cd, -wu: Dauer, Abkühl- und Aufwärmphase, wie beim Empfänger.
• -m: Thread-Mapping, CPU und Empfänger-IP, identisch mit der Serverseite.

Ausgabe und Metriken: Auf dem Empfänger können Sie eine XML mit einer Thread-Aufschlüsselung speichern (Echtzeit, KB/s und MB/s, Mbit/s, Bytes pro Abschluss, Gesamtbandbreite, Puffer/s, Interrupts pro Sekunde, DPC/s, Zyklen/Byte, gesendete/empfangene Pakete, Neuübertragungen, Fehler und %CPU). In einem Beispieltest mit 2 Threads kann das Aggregat im Bereich von mehreren liegen Gbps (z. B. ~9 Gbit/s) auf geeigneten Instanzen und einem gut abgestimmten Netzwerk.

UDP-Leistungstest auf EC2: Um die Datenebene ohne TCP-Überlastungskontrolle zu validieren, verwenden Sie den Schalter -u. Zweidrahtempfänger an den Ports 80–81:
ntttcp -r -u -p 80 -t 60 -cd 5 -wu 5 -v -xml c:\bench.xml -m 1,0,192.168.1.4 1,1,192.168.1.4

Äquivalenter UDP-Sender, unter Berücksichtigung von IP und Ports:
ntttcp -s -u -p 80 -t 60 -cd 5 -wu 5 -m 1,0,192.168.1.4 1,1,192.168.1.4

In UDP sehen Sie MB/s, Mbps, durchschnittliche Größe pro Abschluss und Puffer/s, zusammen mit Interrupt-Zählern und DPCs. Im Gegensatz zu TCP gibt es keine Zustellungsgarantien, sodass Fehler und Verluste deutlicher sichtbar sind, wenn Sie das Netzwerk an seine Grenzen bringen.

Ergebnisse interpretieren: Durchsatz, erneute Übertragungen und Fehler

Durchsatz (MB/s und Mbit/s): ist der effektive Durchsatz. Bei 1 GbE können Sie im Normalfall mit ca. 940 Mbit/s (ca. 112 MB/s) rechnen. Bei 10 GbE sind Werte um 9–9.5 Gbit/s ohne Jumbo Frames sinnvoll und mit optimalen Einstellungen sogar noch besser.

Puffer/s, durchschnittliche Framegröße und Zyklen/Byte: Diese geben Aufschluss über die Last jedes Threads und die Effizienz des Stapels. Hohe Zyklen/Byte deuten darauf hin, dass die CPU für jedes übertragene Byte zu viel arbeitet.

DPC/Interrupts pro SekundeWenn es zu Spitzen kommt, sollten Sie RSS/RSC/RDMA (falls zutreffend), Treiber und CPU-Thread-Zuweisung optimieren. Eine schlechte Zuweisung kann zu Hotspots auf einem einzelnen Kern führen.

Sendungen: Das Ansehen einiger Streams kann unter Last normal sein, aber Anhaltend hohe Zahlen deuten auf Verluste oder Überlastung hinBei einem sauberen 1GbE sollten die Neuübertragungen gering sein. Wenn Sie innerhalb weniger Minuten Tausende sehen, überprüfen Sie die Verkabelung, die Verbindungsqualität, Kollisionen (falsch ausgehandelter Vollduplex-Zustand), Offloads (versuchen Sie, LSO/TSO zum Testen zu deaktivieren), NIC-Warteschlangen und den Pufferdruck.

Fehler: : das Ideal ist Null. Wenn sie erscheinen, suchen Sie nach CRC auf Switches/NIC, inkonsistente MTU, ältere Treiber oder Firewall-/IDS-Regeln, die übermäßig prüfen. Stellen Sie bei Verwendung dieser Regeln die Jumbo-Frame-Konsistenz sicher und stellen Sie sicher, dass beide Endpunkte dieselbe MTU unterstützen.

FallstudienWenn Sie in einem 1-GbE-LAN ​​ca. 112 MB/s erreichen, aber innerhalb von 5 Minuten ca. 3.000 Wiederholungsübertragungen und ca. 400 Fehler sehen, deutet dies auf einen zeitweiligen Verlust hin. Versuchen Sie, Kabel/Port auszutauschen, Treiber zu aktualisieren, die Flusskontrolle zu überprüfen, temporäre Offloads zu deaktivieren und den Vorgang zu wiederholen. Wenn die Wiederholungsübertragungen drastisch sinken, haben Sie das Ziel erreicht.

iperf vs. NTTTCP und andere nützliche Tools

iperf eignet sich hervorragend für schnelle, plattformübergreifende Tests, und hilft Ihnen zu zeigen, ob das Netzwerk 1G/10G zwischen zwei bestimmten Punkten aufrechterhalten kann. Es ist sehr nützlich, um das Netzwerk auszuschließen, wenn das Problem bei der Anwendung oder dem Speicher liegt.

NTTTCP bietet eine feinere Steuerung in Windows (Thread- und CPU-Mapping, asynchrone Modi, detailliertes XML, DPC-/Interrupt-Metriken) und eine Linux-Implementierung, die konsistente Tests ermöglicht. In Microsoft/Azure-Umgebungen ist dies oft der Benchmark.

ctsTraffic (Client-zu-Server-Verkehr) ist ein weiteres Microsoft-Tool zum Generieren und Überprüfen von Datenverkehr. Es kann NTTTCP ergänzen, wenn Sie vielfältigere Client-Server-Muster profilieren möchten.

Methodik zum „Löschen von Bränden“ zwischen TeamsFühren Sie Tests von den betroffenen Hosts über denselben Netzwerkpfad aus. Wiederholen Sie die Tests zu unterschiedlichen Zeitpunkten, fügen Sie kontrollierte UDP-Tests hinzu und erfassen Sie Daten auf der Netzwerkkarte/dem Switch. Nur mit hohem Durchsatz in iperf/NTTTCP, geringen Wiederholungsübertragungen und null Fehlern können Sie mit Daten nachweisen, dass das Netzwerk nicht der Engpass ist.

Nächste Schritte und zugehörige Informationen

Überprüfen Sie MTU und End-to-End-Konsistenz (insbesondere bei der Kombination von Jumbo-Frames). Berücksichtigen Sie bei AWS Placement Groups und Enhanced Networking. Passen Sie bei Azure die VM-Größe an Ihre Durchsatzziele an.

Experimentieren Sie mit der Anzahl der Threads (-m) und der CPU-Pinnung um RSS und mehrere NIC-Warteschlangen zu nutzen. Setzen Sie -ta auf 300 s für stabile Tests und verwenden Sie -xml, um Ergebnisse für Vergleiche beizubehalten.

Wenn Sie Windows und Linux mischen müssen, denken Sie an -ns/-N. Und wenn die Latenz erheblich ist, sollten Sie das TCP-Fenster mit -rb nur vergrößern, um Hypothesen zu validieren. Seien Sie dabei vorsichtig, wenn die automatische Optimierung deaktiviert ist.

Ein praktischer Leitfaden wie dieser, der Befehle, Interpretationen und Anpassungen kombiniert, ermöglicht es Ihnen, Ihr Netzwerk zu messen, zu verstehen und zu verbessern. ohne Störungen durch andere Subsysteme, wodurch deutlich wird, ob die Grenze in der Infrastruktur, der Konfiguration oder dem Anwendungsdesign selbst liegt.