NTTTCP gebruiken op Windows: tests, opdrachten en aanpassingen

Als u de werkelijke prestaties van uw netwerk op Windows (en ook op Linux) wilt meten zonder de opslagruimte of de CPU-omstandigheden die uNTTTCP is een van de meest betrouwbare hulpprogramma's voor het testen van bandbreedte en praktische latentie. Deze Microsoft-tool concentreert de belasting op de netwerklaag en helpt u knelpunten, configuratieproblemen en fysieke verbindingsbeperkingen te detecteren.

In dit artikel hebben we alle essentiële informatie voor het gebruik van NTTTCP verzameld en geordend in één handleiding.: vereisten, installatie op Windows en Linux, commando's sleutel, aanbevolen testparameters (zoals het instellen van een gemeenschappelijke duur met -t), uitvoering in virtuele machines en in Amazon EC2, TCP-vensterafstemming, leesresultaten (MB/s, Mbps, cycli/byte, DPC, interrupts) en hoe hertransmissies en fouten te interpreteren. Je ziet ook wanneer het zinvol is om iperf of andere tools zoals ctsTraffic te gebruiken.

Wat is NTTTCP en waarom zou je het gebruiken?

NTTTCP (NT Test TCP) is een gratis hulpprogramma van Microsoft waarmee u de netwerkprestaties kunt meten., zowel op fysieke als virtuele machines, met een directe focus op de TCP/UDP-stack. Het voordeel hiervan is dat de invloed van andere subsystemen (schijven, back-endservices, enz.) wordt geminimaliseerd, zodat de test het daadwerkelijke gedrag van de verbinding weerspiegelt.

Het is beschikbaar voor Windows en er is een compatibele implementatie voor Linux (ntttcp-for-linux), zodat u homogene testen op verschillende besturingssystemenDit is vooral handig in cloudomgevingen zoals Azure of AWS, waar de configuratie van instanties, netwerkwachtrijen en stuurprogramma's een aanzienlijke impact heeft.

Met NTTTCP kunt u het aantal threads, CPU-toewijzing, poorten en verschillende timers beheren, naast het inschakelen van specifieke modi voor gecombineerd testen tussen Windows en Linux. Dit stelt u in staat om realistische belastingen te simuleren, meerdere NIC-wachtrijen te verzadigen en de impact op interrupts, DPC, cycli/byte en CPU-gebruik te observeren.

Voorbeeld van vereisten en omgeving

Zorg er allereerst voor dat u over twee computers of virtuele machines beschikt die onderling verbinding kunnen maken. (routes, beveiligings-/netwerkgroepen, firewall) en rechten om tools te installeren/uit te voeren. Het is een goed idee om beheerdersrechten te hebben op Windows en sudo op Linux.

Voorbeeld van parameters die in de tekst worden gebruikt (u kunt ze aanpassen):

parameter	waarde
Ontvanger IP	10.0.0.5
CPU-cores per VM	2

Op 1GbE-netwerken geeft een aanhoudende overdrachtssnelheid van ongeveer 112 MB/s doorgaans aan dat u dicht bij het theoretische maximum zit., mits de TCP-stack goed is afgestemd en er geen verliezen zijn. Op verbindingen van 10 GbE of hoger is het essentieel om het TCP-venster te controleren en in sommige gevallen jumboframes consequent in te schakelen.

Installatie en voorbereiding op Windows en Linux

WindowsDownload de nieuwste versie van NTTTCP van de officiële Microsoft-repository (GitHub), pak het pakket uit en open een console met beheerdersrechten. ga naar de directory die overeenkomt met uw systeemarchitectuur (bijvoorbeeld x64) om het hulpprogramma uit te voeren.

Linux: Om ntttcp-for-linux te gebruiken, moet je eerst de afhankelijkheden installeren en compileren. Op Ubuntu hoef je alleen maar build-essentiële y git; op SUSE, met git-core, gcc y maken. Kloon en compileer vervolgens het project.

Voorbereidingsopdrachten in Ubuntu (pas ze aan als uw distro anders is):

Draait op de Linux VM en controleer of er geen fouten zijn:
sudo apt-get update && sudo apt-get -y install build-essential git

Voorbereidingsopdrachten in SUSE (installeert pakketten en lost afhankelijkheden op als deze voorkomen):
sudo zypper in -y git-core gcc make

Klonen en compileren van ntttcp-for-linux (van elke compatibele distro):
git clone https://github.com/Microsoft/ntttcp-for-linux && cd ntttcp-for-linux/src && sudo make && sudo make install

Hoe u benchmarks uitvoert met NTTTCP op Windows

Normaal gesproken wordt aanbevolen om een ​​duur van 300 seconden (-t 300) in te stellen op zowel de zender als de ontvanger. Om de doorvoer te stabiliseren en CPU- en interruptgegevens gedurende een langere periode te monitoren. Beide kanten moeten dezelfde -t-waarde gebruiken.

Op de ontvanger (Windows), voer uit vervang het aantal cores en het bestemmings-IP door het uwe:
ntttcp -r -m [num_de_nucleos x 2],*,10.0.0.5 -t 300

Voorbeeldontvanger met 2 kernen (4 draden) met behulp van het IP uit het voorbeeld:
ntttcp -r -m 4,*,10.0.0.5 -t 300

Op de zender (Windows) is het commando analoog maar door -r te veranderen in -s om aan te geven dat het het volgende verzendt:
ntttcp -s -m [num_de_nucleos x 2],*,10.0.0.5 -t 300

Voorbeeld van een 4-draadszender verwijzend naar de ontvanger 10.0.0.5:
ntttcp -s -m 4,*,10.0.0.5 -t 300

Waar je op moet letten bij het verlaten: Threaddoorvoer, totale MB/s, gemiddelde framegrootte, buffers/s, cycli/byte, DPC, interrupts, verzonden/ontvangen pakketten, hertransmissies, fouten en %CPU. Deze velden helpen u te zien of de bandbreedte wordt beperkt door de TCP-stack, de netwerkkaart of de CPU.

Hoe NTTTCP op Linux te draaien

In Linux is de syntaxis vrijwel identiek.Houd er rekening mee dat als u -t niet opgeeft, de standaardduur doorgaans 60 seconden is. Dit is mogelijk niet voldoende voor een stabiele meting.

Ontvanger (Linux) met 4 threads en 5 minuten duur:
ntttcp -r -m 4,*,10.0.0.5 -t 300

Zender (Linux) gericht op dezelfde ontvanger en dezelfde duur:
ntttcp -s -m 4,*,10.0.0.5 -t 300

De typische uitvoer op Linux vat het aantal gemaakte verbindingen, de duur, het totale aantal bytes, de doorvoer (Mbps), het aantal hertransmissies (retrans segs) en het CPU-gebruik samen.Daarnaast ziet u indicatoren zoals cycli/byte of het percentage CPU-gebruik, die nuttig zijn om inzicht te krijgen in de stack-efficiëntie.

Gemengde tests tussen Windows en Linux

Om te testen tussen Windows en Linux, schakelt u de no-sync-modus in. Om interne handshakingsproblemen te voorkomen: voeg in Windows toe -NS en in Linux voegt het toe -NDit vereenvoudigt de coördinatie tussen eindpunten en voorkomt blokkades als gevolg van implementatieverschillen.

Relevante netwerkinstellingen: TCP/IP-venstergrootte

Op 1GbE-verbindingen met een lage latentie biedt het standaard TCP-venster (~64 KB met SO_RCVBUF in NTttcp) doorgaans goede prestaties.Hierdoor hoeft u de stackparameters niet aan te passen voor eenvoudige LAN-gevallen.

Op netwerken met een hoge latentie of op 10GbE en hoger kan het standaardvenster te kort schieten., waardoor de effectieve doorvoer wordt verminderd. In dit geval is het raadzaam om de TCP-venstergrootte aan te passen om een ​​product met een hogere bandbreedte x vertraging te ondersteunen.

Met NTTTCP kunt u het venster statisch vastzetten met -rb, waarmee stack-autotuning wordt uitgeschakeld. Gebruik dit alleen als u de implicaties volledig begrijpt, omdat het forceren van een groot venster in ongepaste scenario's de prestaties kan verslechteren.

Als algemene richtlijn geldt dat u met de standaardinstellingen moet beginnen en alleen moet opschalen als dat in uw geval nodig is. (hoge latentie, WAN, multi-hop). Vul deze tests aan met de netwerkafstemmingsgidsen van het besturingssysteem voor blijvende aanpassingen.

NTTTCP op Amazon EC2 (Windows)-instanties

Als u met AWS werkt, kunt u NTTTCP gebruiken om optimale instantietypen, -grootten en -configuraties te kiezen.Met de tests kunt u de werkelijke prestaties vergelijken met de door AWS gepubliceerde prestaties voor elke EC2-familie.

Aanbevolen vereisten voor EC2 (Windows):

• Twee Windows-instanties opstarten voor netwerktesten.
• Controleer of ze Enhanced Networking ondersteunen (bijgewerkte drivers en ondersteund exemplaartype).
• Pas de MTU aan als ze zich niet in dezelfde plaatsingsgroep bevinden of gebruik geen jumboframes, waarbij de consistentie van begin tot eind behouden blijft.
• Controleer connectiviteit (RDP, ping indien van toepassing, routes en beveiliging).

Installatie in beide gevallen: Download de nieuwste versie van NTttcp van Microsoft, pak het uit in een map en open het. CMD Als beheerder. Voer de directory in die overeenkomt met de architectuur van uw instantie voordat u de uitvoering start.

Havens en veiligheid: Standaard gebruikt NTTTCP poort 5001 voor TCP en UDP, hoewel u dit kunt wijzigen met -p. verzekerd dat Beveiligingsgroepen en Windows Firewall staan ​​verkeer toe vereist en verbindingen met ntttcp.exe (inkomend en uitgaand).

TCP-prestatietest op EC2 (ontvanger): initialiseert de listener vanaf de gekozen poort. Voorbeeld met twee threads op poorten 80-81, toegewezen aan CPU's 0 en 1:
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

Betekenis van bovenstaande parameters (ontvanger):

• -r: ontvangstmodus.
• -p 80: basispoort van de eerste thread (verhoogd met extra thread).
• -een 6: Asynchrone I/O met 6 overlappende ontvangstbuffers per thread.
• -t 60: testduur in seconden.
• -cd 5: 5s afkoeling om het einde van de test te stabiliseren.
• -wu 5: 5s warming-up om de start te stabiliseren.
• -v: gedetailleerde uitvoer.
• -xml c:\bench.xml: slaat resultaten op in XML in het opgegeven pad (standaard xml.txt).
• -m: Sessietoewijzing (threads, CPU-ID, ontvanger-IP), sessies scheiden door spaties.

TCP-prestatietest op EC2 (Sender): Gebruik dezelfde parameters, schakel over naar de verzendmodus en richt u in beide opdrachten op het IP-adres van de ontvanger:
ntttcp -s -p 80 -a -t 60 -cd 5 -wu 5 -m 1,0,192.168.1.4 1,1,192.168.1.4

Betekenis van de specifieke parameters (uitgever):

• -s: verzendmodus.
• -p 80: basispoort per thread (in stappen per thread).
• -a: overlappende verzendbuffers per thread (standaard 2, geef dit op als u een andere waarde wilt).
• -t, -cd, -wu: duur, afkoeling en warming-up, hetzelfde als op de ontvanger.
• -m: Thread mapping, CPU en ontvanger-IP, identiek aan de serverkant.

Output en statistieken: Op de ontvanger kunt u een XML opslaan met een thread-indeling (realtime, KB/s en MB/s, Mbps, bytes per voltooiing, totale bandbreedte, buffers/s, interrupts per seconde, DPC/s, cycli/byte, verzonden/ontvangen pakketten, hertransmissies, fouten en %CPU). In een steekproef met 2 threads kan het totaal binnen het bereik van meerdere liggen. Gbps (bijv. ~9 Gbps) op geschikte instanties en een goed afgestemd netwerk.

UDP-prestatietest op EC2: Om het datavlak te valideren zonder TCP-congestiecontrole, gebruikt u de schakelaar -uTwee-draadsontvanger op poorten 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

Equivalente UDP-zender, met inachtneming van IP en poorten:
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 ziet u MB/s, Mbps, gemiddelde grootte per voltooiing en buffers/s, samen met interrupttellers en DPC's. In tegenstelling tot TCP zijn er geen leveringsgaranties, waardoor fouten en verliezen beter zichtbaar zijn als u het netwerk tot het uiterste drijft.

Resultaten interpreteren: doorvoer, hertransmissies en fouten

Doorvoer (MB/s en Mbps): is de effectieve doorvoer. Bij 1 GbE kun je ~940 Mbps (ongeveer 112 MB/s) verwachten als alles goed gaat. Bij 10 GbE zijn niveaus van bijna 9–9.5 Gbps redelijk zonder jumbo frames en beter met optimale instellingen.

Buffers/s, gemiddelde framegrootte en cycli/byte: Deze geven aan hoeveel belasting elke thread verplaatst en hoe efficiënt de stack is. Hoge cycli per byte duiden erop dat de CPU te hard werkt voor elke verzonden byte.

DPC/onderbrekingen per secondeAls ze pieken, overweeg dan om RSS/RSC/RDMA (indien van toepassing), drivers en CPU-threadtoewijzing te optimaliseren. Slechte toewijzing kan hotspots op één core creëren.

Uitzendingen: Het bekijken van sommige streams kan normaal zijn onder belasting, maar Aanhoudend hoge aantallen duiden op verliezen of congestieMet een schone 1GbE zouden de hertransmissies laag moeten zijn. Als u er duizenden in een paar minuten ziet, controleer dan de bekabeling, de verbindingskwaliteit, botsingen (full-duplex verkeerd onderhandeld), offloads (probeer LSO/TSO uit te schakelen voor testdoeleinden), NIC-wachtrijen en bufferdruk.

fouten: : het ideaal is nul. Als ze verschijnen, zoek dan naar CRC op switches/NIC's, inconsistente MTU, oudere drivers of firewall-/IDS-regels die overmatig inspecteren. Zorg voor consistentie van jumbo-frames als u deze gebruikt en zorg ervoor dat beide eindpunten dezelfde MTU ondersteunen.

case studiesAls je ~112 MB/s haalt op een 1 GbE LAN, maar ~3.000 hertransmissies en ~400 fouten in 5 minuten ziet, wijst dit op intermitterend dataverlies. Probeer de kabel/poort te vervangen, drivers bij te werken, flow control te controleren, tijdelijke offloads uit te schakelen en herhaal het proces. Als het aantal hertransmissies drastisch daalt, heb je het doel bereikt.

iperf vs NTTTCP en andere nuttige tools

iperf is uitstekend geschikt voor snelle, platformonafhankelijke tests, en helpt u aantonen of het netwerk 1G/10G tussen twee specifieke punten aankan. Dit is erg handig om het netwerk uit te sluiten wanneer het probleem bij de applicatie of opslag ligt.

NTTTCP biedt meer gedetailleerde controle in Windows (thread- en CPU-mapping, asynchrone modi, gedetailleerde XML, DPC/interrupt-metrieken) en een Linux-implementatie die consistent testen mogelijk maakt. In Microsoft/Azure-omgevingen is dit vaak de benchmark.

ctsTraffic (client-naar-serververkeer) is een andere Microsoft-tool voor het genereren en verifiëren van verkeer. Het kan NTTTCP aanvullen als u meer gevarieerde client-serverpatronen wilt profileren.

Methodiek voor het blussen van brandjes tussen teamsVoer tests uit vanaf de betrokken hosts via hetzelfde netwerkpad. Herhaal dit op verschillende tijdstippen, voeg gecontroleerde UDP-tests toe en verzamel vastleggingen op de netwerkkaart/switch. Alleen met een hoge doorvoer in iperf/NTTTCP, lage hertransmissies en nul fouten kunt u met data aantonen dat het netwerk niet de bottleneck is.

Volgende stappen en gerelateerde informatie

Controleer MTU en end-to-end consistentie (vooral als u jumboframes combineert). Overweeg op AWS plaatsingsgroepen en verbeterde netwerken. Stem op Azure de VM-grootte af op uw doorvoerdoelen.

Experimenteer met het aantal threads (-m) en CPU-pinning Om te profiteren van RSS en meerdere NIC-wachtrijen. Stel -ta in op 300 s voor stabiele tests en gebruik -xml om de resultaten te bewaren voor vergelijking.

Als je Windows en Linux moet mixen, onthoud -ns/-N. En als de latentie aanzienlijk is, overweeg dan om het TCP-venster alleen met -rb te vergroten om hypothesen te valideren. Wees voorzichtig met uitgeschakelde autotuning.

Met een praktische gids als deze, waarin opdrachten, interpretatie en aanpassingen worden gecombineerd, kunt u uw netwerk meten, begrijpen en verbeteren. zonder ruis van andere subsystemen, waardoor het duidelijk is of de beperking ligt in de infrastructuur, de configuratie of het ontwerp van de applicatie zelf.