Come utilizzare NTTTCP su Windows: test, comandi e modifiche

Se hai bisogno di misurare le prestazioni effettive della tua rete su Windows (e Linux) senza essere limitato dallo spazio di archiviazione o dall'utilizzo della CPU , NTTTCP è una delle utility più affidabili per testare la larghezza di banda e la latenza effettiva. Questo strumento Microsoft concentra il carico sul livello di rete e ti aiuta a individuare colli di bottiglia, problemi di configurazione e limitazioni del collegamento fisico.

In questo articolo, abbiamo raccolto e riorganizzato in un'unica guida tutto ciò che è essenziale per utilizzare NTTTCP : requisiti, installazione su Windows e Linux, comandi principali , parametri di test consigliati (come l'impostazione di una durata comune con -t), esecuzione su macchine virtuali e Amazon EC2, ottimizzazione della finestra TCP, lettura dei risultati (MB/s, Mbps, cicli/byte, DPC, interruzioni) e come interpretare ritrasmissioni ed errori. Scoprirai anche quando è opportuno utilizzare iperf o altri strumenti come ctsTraffic.

Che cos'è NTTTCP e perché utilizzarlo?

NTTTCP (NT Test TCP) è un'utilità gratuita di Microsoft progettata per misurare le prestazioni di rete sia su computer fisici che su macchine virtuali, concentrandosi direttamente sullo stack TCP/UDP. Il suo vantaggio risiede nella capacità di minimizzare l'influenza di altri sottosistemi (dischi, servizi in background, ecc.), in modo che il test rifletta accuratamente il comportamento effettivo del collegamento.

È disponibile per Windows ed esiste un'implementazione compatibile per Linux (ntttcp-for-linux) , che consente di eseguire test coerenti su diversi sistemi operativi . È particolarmente utile in ambienti cloud come Azure o AWS, dove la configurazione dell'istanza, le code di rete e i driver hanno un impatto significativo.

NTTTCP consente di controllare il numero di thread, la mappatura della CPU, le porte e vari timer , oltre ad abilitare modalità specifiche per test misti Windows e Linux. In questo modo, è possibile simulare carichi di lavoro realistici, saturare più code di schede di rete e osservare l'impatto su interrupt, DPC, cicli per byte e utilizzo della CPU.

Esempio di requisiti ed ambiente

Innanzitutto, assicurati di avere due computer o macchine virtuali collegati tra loro (percorsi, gruppi di sicurezza/rete, firewall) e con i privilegi necessari per installare/eseguire gli strumenti. Su Windows si consigliano i privilegi di amministratore, mentre su Linux sono consigliati i privilegi sudo.

Esempio di parametri utilizzati nel testo (è possibile adattarli) :

parametro	valore
IP del destinatario	10.0.0.5
Core CPU per VM	2

Sulle reti 1 GbE, una velocità di trasferimento sostenuta di circa 112 MB/s indica in genere che ci si avvicina al massimo teorico , a condizione che lo stack TCP sia configurato correttamente e non vi siano perdite. Su collegamenti 10 GbE o superiori, sarà essenziale controllare la finestra TCP e, in alcuni casi, abilitare costantemente i jumbo frame.

Installazione e preparazione su Windows e Linux

Windows : Scarica l'ultima versione di NTTTCP dal repository ufficiale Microsoft (GitHub), estrai il pacchetto e apri un prompt dei comandi con privilegi di amministratore. Quindi, spostati nella directory corrispondente all'architettura del tuo sistema (ad esempio, x64) per eseguire l'utilità.

Linux : Per utilizzare ntttcp-for-linux, è necessario prima installare le dipendenze e compilarlo. Su Ubuntu, build-essential e git saranno sufficienti ; su SUSE, git-core , gcc e make saranno sufficienti . Successivamente, clonare e compilare il progetto.

Comandi di preparazione in Ubuntu (modificali se la tua distribuzione è diversa):

Funziona sulla VM Linux e verificare che non ci siano errori:
sudo apt-get update && sudo apt-get -y install build-essential git

Comandi di preparazione in SUSE (installa i pacchetti e risolve le dipendenze se presenti):
sudo zypper in -y git-core gcc make

Clonazione e compilazione di ntttcp-for-linux (da qualsiasi distribuzione compatibile):
git clone https://github.com/Microsoft/ntttcp-for-linux && cd ntttcp-for-linux/src && sudo make && sudo make install

Come eseguire benchmark con NTTTCP su Windows

La raccomandazione usuale è di impostare una durata di 300 secondi (-t 300) sia sul mittente che sul destinatario per stabilizzare il throughput e osservare le metriche di CPU e interrupt per un periodo significativo. Entrambe le parti dovrebbero utilizzare lo stesso valore -t.

Sul ricevitore (Windows), eseguire sostituendo il numero di core e l'IP di destinazione con i tuoi:
ntttcp -r -m [num_de_nucleos x 2],*,10.0.0.5 -t 300

Esempio di ricevitore con 2 core (4 fili) utilizzando l'IP dell'esempio:
ntttcp -r -m 4,*,10.0.0.5 -t 300

Sul trasmettitore (Windows) il comando è analogo ma cambiando -r in -s per indicare che invia:
ntttcp -s -m [num_de_nucleos x 2],*,10.0.0.5 -t 300

Esempio di un trasmettitore a 4 fili puntando al ricevitore 10.0.0.5:
ntttcp -s -m 4,*,10.0.0.5 -t 300

Cosa cercare nell'output : throughput per thread, MB/s totali, dimensione media del frame, buffer/s, cicli/byte, DPC, interruzioni, pacchetti inviati/ricevuti, ritrasmissioni, errori e %CPU. Questi campi aiutano a determinare se la larghezza di banda è limitata dallo stack TCP, dalla scheda di rete o dalla CPU.

Come eseguire NTTTCP su Linux

In Linux, la sintassi è praticamente identica . Ricorda che se non specifichi -t, la durata predefinita è solitamente di 60 secondi, che potrebbe non essere sufficiente per una misurazione stabile.

Ricevitore (Linux) con 4 thread e durata di 5 minuti:
ntttcp -r -m 4,*,10.0.0.5 -t 300

Trasmettitore (Linux) mirati allo stesso ricevitore e alla stessa durata:
ntttcp -s -m 4,*,10.0.0.5 -t 300

L'output tipico di Linux riassume le connessioni create, la durata, il totale dei byte, il throughput (Mbps), le ritrasmissioni (secondi di ritrasmissione) e l'utilizzo della CPU . Vedrai anche metriche come cicli/byte e percentuale di utilizzo della CPU, utili per comprendere l'efficienza dello stack.

Test misti tra Windows e Linux

Per eseguire test tra un sistema Windows e un sistema Linux, abilitare la modalità non sincronizzata per evitare problemi di handshake interni: su Windows aggiungere `-ns` e su Linux aggiungere `-N` . Questo semplifica il coordinamento tra gli endpoint e previene i deadlock dovuti a differenze di implementazione.

Impostazioni di rete rilevanti: dimensione della finestra TCP/IP

Su collegamenti 1 GbE a bassa latenza, la finestra TCP predefinita (~64 KB con SO_RCVBUF in NTttcp) offre solitamente buone prestazioni . Ciò evita di dover modificare i parametri dello stack per semplici scenari LAN.

Nelle reti ad alta latenza o a velocità di 10 GbE e superiori, la finestra predefinita potrebbe risultare insufficiente , riducendo la velocità di trasmissione effettiva. In questi casi, è consigliabile regolare la dimensione della finestra TCP per supportare un prodotto larghezza di banda x latenza maggiore.

NTTTCP consente di impostare staticamente la dimensione della finestra con l'opzione `-rb` , che disabilita l'ottimizzazione automatica dello stack. Utilizzare questa opzione solo se si comprendono appieno le implicazioni, poiché forzare una finestra di grandi dimensioni in scenari inappropriati può compromettere le prestazioni.

In linea generale, iniziate con le impostazioni predefinite e aumentatele solo se la vostra situazione lo richiede (latenza elevata, WAN, più hop). Integrate questi test con le guide di ottimizzazione della rete del sistema operativo per le regolazioni permanenti.

NTTTCP su istanze Amazon EC2 (Windows)

Se operi su AWS, puoi utilizzare NTTTCP per scegliere i tipi, le dimensioni e le configurazioni di istanza ottimali . I test ti aiuteranno a confrontare le prestazioni effettive con le prestazioni pubblicate da AWS per ogni famiglia di EC2.

Passaggi preliminari consigliati in EC2 (Windows) :

• Avvia due istanze di Windows per i test di rete.
• Verificare che supportino la rete avanzata (driver aggiornati e tipo di istanza supportato).
• Regolare l'MTU se non sono nello stesso gruppo di posizionamento o non utilizzano frame jumbo, mantenendo la coerenza end-to-end.
• Controllare la connettività (RDP, ping se applicabile, percorsi e sicurezza).

Installazione su entrambe le istanze : Scarica l'ultima versione di NTttcp da Microsoft, estraila in una cartella e apri il prompt dei comandi come amministratore. Accedi alla directory corrispondente all'architettura della tua istanza prima di eseguire il comando.

Porte e sicurezza : per impostazione predefinita, NTTTCP utilizza la porta 5001 per TCP e UDP, ma è possibile modificarla con l'opzione -p . Assicurarsi che i gruppi di sicurezza e il firewall di Windows consentano il traffico e le connessioni necessarie a ntttcp.exe (in entrata e in uscita).

Test delle prestazioni TCP su EC2 (ricevitore): inizializza l'ascoltatore dalla porta scelta. Esempio con due thread sulle porte 80–81, assegnati alle CPU 0 e 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

Significato dei parametri sopra indicati (recettore) :

• -r: modalità di ricezione.
• -p 80: porta base del primo thread (incrementata dal thread aggiuntivo).
• -un 6: I/O asincrono con 6 buffer di ricezione sovrapposti per thread.
• -t 60: durata del test in secondi.
• -cd 5: 5 secondi di tempo di recupero per stabilizzare la fine del test.
• -wu 5: 5 secondi di riscaldamento per stabilizzare la partenza.
• -v: output dettagliato.
• -xml c:\bench.xml: salva i risultati in formato XML nel percorso specificato (per impostazione predefinita xml.txt).
• -m: Mappatura delle sessioni (thread, ID CPU, IP del ricevitore), separando le sessioni tramite spazi.

Test delle prestazioni TCP su EC2 (mittente): Utilizzare gli stessi parametri, passando alla modalità di invio e prendendo di mira l'IP del destinatario in entrambi i comandi:
ntttcp -s -p 80 -a -t 60 -cd 5 -wu 5 -m 1,0,192.168.1.4 1,1,192.168.1.4

Significato dei parametri specifici (emettitore) :

• -s: modalità di spedizione.
• -p 80: porta base per thread (incrementi per thread).
• -a: buffer di invio sovrapposti per thread (predefinito 2, specificarlo se si desidera un altro valore).
• -t, -cd, -wu: durata, fase di raffreddamento e riscaldamento, come sul ricevitore.
• -m: Thread mapping, CPU e IP del ricevitore, identici al lato server.

Output e metriche : Il ricevitore può memorizzare un file XML con una ripartizione per thread (tempo reale, KB/s e MB/s, Mbps, byte per completamento, larghezza di banda totale, buffer/s, interruzioni al secondo, DPC/s, cicli/byte, pacchetti inviati/ricevuti, ritrasmissioni, errori e %CPU). In un test di esempio con 2 thread, la velocità di trasmissione aggregata può raggiungere valori dell'ordine di diversi Gbps (ad esempio, ~9 Gbps) in condizioni adeguate e con una rete ben ottimizzata.

Test delle prestazioni UDP su EC2: Per convalidare il piano dati senza controllo della congestione TCP, utilizzare lo switch -uRicevitore a due fili sulle porte 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

Trasmettitore UDP equivalente, rispettando IP e porte:
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 vedrai MB/s, Mbps, dimensione media per completamento e buffer/s , insieme ai contatori di interrupt e DPC. A differenza di TCP, non ci sono garanzie di consegna, quindi errori e perdite sono più evidenti se si spinge la rete al limite.

Interpretare i risultati: throughput, ritrasmissioni ed errori

Throughput (MB/s e Mbps) : si tratta della larghezza di banda effettiva. Con una connessione 1 GbE, ci si può aspettare circa 940 Mbps (circa 112 MB/s) se tutto funziona correttamente. Con una connessione 10 GbE, valori vicini a 9-9.5 Gbps sono ragionevoli senza jumbo frame e migliori con una configurazione ottimale.

Buffer/s, dimensione media del frame e cicli/byte : questi parametri indicano la quantità di lavoro gestita da ciascun thread e l'efficienza dello stack. Un valore elevato di cicli/byte suggerisce che la CPU sta lavorando troppo intensamente per ogni byte trasferito.

Interruzioni DPC/se al secondo : se vengono attivate, valutare l'ottimizzazione di RSS/RSC/RDMA (se applicabile), dei driver e dell'allocazione dei thread per CPU. Un'allocazione inadeguata può creare punti critici su un singolo core.

Ritrasmissioni : Un certo numero di ritrasmissioni può essere normale sotto carico, ma un numero elevato e costante indica perdite o congestione . Con una connessione 1 GbE stabile, le ritrasmissioni dovrebbero essere basse; se ne vedi migliaia in pochi minuti, controlla il cablaggio, la qualità del collegamento, le collisioni (full-duplex negoziato male), gli offload (prova a disabilitare LSO/TSO per i test), le code NIC e la pressione del buffer.

Errori : idealmente, zero. Se si verificano, verificare la presenza di errori CRC su switch/schede di rete , MTU incoerenti, driver obsoleti o regole firewall/IDS che effettuano controlli eccessivi. Assicurarsi della coerenza dei frame jumbo, se utilizzati, e che entrambe le estremità supportino lo stesso MTU.

Esempi pratici : se su una LAN 1 GbE si ottengono circa 112 MB/s ma si registrano circa 3.000 ritrasmissioni e circa 400 errori in 5 minuti, ci sono segnali di una perdita di pacchetti intermittente. Provate a cambiare il cavo/la porta, ad aggiornare i driver, a verificare il controllo di flusso, a disabilitare gli offload temporanei e ripetete la procedura. Se le ritrasmissioni diminuiscono drasticamente, avete individuato il problema.

iperf vs NTTTCP e altri strumenti utili

iperf è eccellente per test rapidi e multipiattaforma e aiuta a determinare se la rete è in grado di mantenere velocità di 1G/10G tra due punti specifici. È molto utile per escludere problemi di rete quando il problema risiede nell'applicazione o nello storage.

NTTTCP offre un controllo più preciso su Windows (mappatura di thread e CPU, modalità asincrone, XML dettagliato, metriche DPC/interrupt) e un'implementazione Linux che facilita test coerenti. Negli ambienti Microsoft/Azure, è spesso lo standard.

ctsTraffic (Client to Server Traffic) è un altro strumento Microsoft per la generazione e la verifica del traffico. Può essere utilizzato in aggiunta a NTTTCP se si desidera analizzare modelli di traffico client-server più vari.

Metodologia per "spegnere gli incendi" tra i team : eseguire test dagli host interessati e sullo stesso percorso di rete. Ripetere in momenti diversi, aggiungere test UDP controllati e raccogliere dati sulla scheda di rete/switch. Solo con un throughput elevato in iperf/NTTTCP, una bassa ritrasmissione e zero errori sarà possibile dimostrare con i dati che la rete non è il collo di bottiglia.

Prossimi passi e informazioni correlate

Verifica l'MTU e la coerenza end-to-end (soprattutto se stai combinando frame jumbo). In AWS, valuta i gruppi di posizionamento e la rete avanzata. In Azure, allinea le dimensioni della macchina virtuale ai tuoi obiettivi di throughput.

Sperimenta con il numero di thread (-m) e la correzione per CPU per sfruttare RSS e le code multiple delle schede di rete. Imposta -ta a 300 secondi per test stabili e usa -xml per salvare i risultati per il confronto.

Se proprio devi utilizzare sia Windows che Linux , ricorda di usare le opzioni -ns/-N. Inoltre, se la latenza è significativa, valuta la possibilità di aumentare la finestra TCP con l'opzione -rb solo per convalidare le ipotesi, facendo attenzione se l'ottimizzazione automatica è disabilitata.

Una guida pratica come questa, che combina comandi, interpretazione e regolazioni, vi permetterà di misurare, comprendere e migliorare la vostra rete senza interferenze da parte di altri sottosistemi, chiarendo se il limite risiede nell'infrastruttura, nella configurazione o nella progettazione stessa dell'applicazione.