Rete 2,5/10 GbE lenta: come scoprire il vero collo di bottiglia e sfruttare tutta la velocità

Una rete Ethernet da 2,5 o 10 Gbps dovrebbe consentire di trasferire file a velocità decisamente superiori rispetto a una tradizionale connessione Gigabit. Eppure, può capitare che un computer Windows 11 dotato di scheda 2,5 GbE non superi i 110 MB/s durante la copia di un file, oppure che un NAS collegato a 10 Gbps trasferisca dati a poche centinaia di megabyte al secondo.

Il primo sospetto cade sul cavo Ethernet, sullo switch o sulla scheda di rete. Il problema, però, potrebbe trovarsi altrove: nel disco del NAS, in un adattatore USB, nella CPU, nel driver di rete o nel protocollo SMB utilizzato per condividere i file.

Per capire quale elemento impedisce di sfruttare tutta la banda disponibile è possibile svolgere una sequenza di test, partendo dalle verifiche più semplici e passando a quelle più approfondite soltanto quando i risultati lo richiedono.

Quanto dovrebbe essere veloce una rete 2,5 o 10 GbE?

Le schede Ethernet dichiarano la velocità in gigabit al secondo (Gbps), mentre Esplora file di Windows mostra normalmente la velocità di copia in megabyte al secondo (MB/s).

Un byte equivale a 8 bit: per convertire una velocità espressa in Gbps in MB/s si moltiplica quindi per 1.000 e si divide per 8. Una rete 2,5 GbE ha una capacità nominale di 312,5 MB/s, mentre una connessione 10 GbE arriva teoricamente a 1.250 MB/s.

Si tratta però di valori teorici:  una parte della banda è utilizzata dalle intestazioni Ethernet, IP e TCP e dagli altri meccanismi necessari per il trasferimento dati.

Collegamento Ethernet	Capacità teorica	Throughput TCP indicativo
1 GbE	125 MB/s	110-118 MB/s
2,5 GbE	312,5 MB/s	280-295 MB/s
5 GbE	625 MB/s	550-590 MB/s
10 GbE	1.250 MB/s	1.100-1.180 MB/s

Gli intervalli riportati rappresentano valori indicativi per test TCP ben ottimizzati in condizioni favorevoli, non risultati garantiti su qualunque configurazione.

Se un computer trasferisce file a circa 280 MB/s attraverso una rete 2,5 GbE, il risultato può essere considerato molto buono. Se invece si ferma a 110 MB/s, valore caratteristico di una connessione Gigabit, è opportuno approfondire. Prima di procedere bisogna però comprendere che esistono tre velocità distinte:

1. Velocità negoziata dalla scheda di rete con lo switch o con il dispositivo direttamente collegato.
2. Throughput realmente ottenibile trasferendo dati tra due computer, senza appoggiarsi alle unità di memorizzzione.
3. Velocità osservata durante una normale copia di file. Questa misura può essere molto inferiore alle altre due senza che la connessione Ethernet presenti alcun malfunzionamento.

Controllare la velocità negoziata: il primo test su Windows e Linux

Una scheda 2,5 GbE può collegarsi a uno switch a 1 Gbps e negoziare automaticamente una connessione Gigabit: il collegamento si adatta alle capacità del dispositivo più lento.

Per controllare la velocità del collegamento Ethernet in Windows 11 basta aprire una finestra PowerShell quindi incollarvi quanto segue:

Get-NetAdapter | Select-Object Name, InterfaceDescription, Status, LinkSpeed

Il comando mostra le interfacce di rete riconosciute da Windows, il relativo stato e la velocità negoziata.

Se la scheda supporta 2,5 Gbps e LinkSpeed riporta 2,5 Gbps, il collegamento tra il PC e il dispositivo direttamente connesso sta funzionando alla velocità nominale prevista. Questo non garantisce, tuttavia, che l’intero percorso fino all’altro PC, al server o al NAS sia a 2,5 Gbps.

Il PC potrebbe essere collegato a una porta 2,5 GbE dello switch mentre il NAS utilizza una porta Gigabit. In tale situazione Windows continuerà a mostrare 2,5 Gbps, ma il traffico verso il NAS dovrà attraversare anche un collegamento a 1 Gbps, con le prestazioni che si abbatteranno verticalmente.

Verificare la velocità Ethernet su Linux

Su Linux si può utilizzare il comando ethtool, disponibile nei repository delle principali distribuzioni. Su Ubuntu o Debian:

sudo apt install ethtool

Per identificare il nome dell’interfaccia, si può usare:

ip -br link

Supponendo che la scheda sia identificata come enp3s0, basta eseguire:

sudo ethtool enp3s0

Che cosa fare se la velocità negoziata è inferiore al previsto

Il controllo più utile consiste nel collegare temporaneamente i due dispositivi con un cavo corto e sicuramente adeguato, evitando prese a muro, patch panel o adattatori intermedi, quando la configurazione lo consente:

• Se la velocità negoziata aumenta, il problema si trova verosimilmente nel percorso di cablaggio precedentemente utilizzato.
• Se la velocità resta invariata, occorre verificare le specifiche di entrambe le porte: una scheda 10 GbE non può ovviamente negoziare 10 Gbps con uno switch dotato soltanto di porte Gigabit.

È importante anche verificare quali velocità sono supportate: non tutte le interfacce 10 GbE supportano automaticamente anche 2,5 e 5 Gbps: alcune implementano esclusivamente combinazioni differenti di velocità.

Un’ulteriore precauzione riguarda l’impostazione Speed & Duplex del driver: di solito è preferibile lasciarla su Auto Negotiation, evitando di forzare manualmente una velocità prima di aver accertato la causa del problema. Quando il collegamento negozia correttamente 2,5 o 10 Gbps, si può passare alla verifica successiva.

La copia dei file è lenta: come capire se dipende dalla rete oppure dai dischi

Supponiamo che Windows indichi una connessione a 2,5 Gbps, ma la copia di un file verso il NAS non superi 110 MB/s.

In prima battuta bisognerebbe chiedersi se i due dispositivi coinvolti nella comunicazione siano capaci di scambiarsi dati più rapidamente di 110 MB/s, indipendentemente dai dischi.

Per scoprirlo si utilizza un generatore di traffico TCP: lo strumento invia dati tra due applicazioni in esecuzione su computer differenti senza dover leggere un file sorgente o scrivere un file di destinazione.

Se il test raggiunge circa 2,3 Gbps, pari a 287,5 MB/s, ma la copia dei file resta a 110 MB/s, la connessione è capace di trasportare dati molto più velocemente di quanto osservato durante la copia. Il sospetto si sposta quindi verso sistema di archiviazione, il protocollo SMB o le risorse utilizzate dalle applicazioni.

Se anche il test TCP si ferma intorno a 900 Mbps (ovvero circa 110 MB/s), invece, è necessario approfondire la capacità del percorso di rete e degli endpoint.

NTTTCP o iPerf3? La scelta dipende dai sistemi operativi

iPerf3 è uno degli strumenti più conosciuti per misurare le prestazioni delle reti TCP/IP, ma Microsoft ne sconsiglia l’utilizzo su Windows per il benchmarking sintetico.

Come avevamo spiegato a suo tempo, Microsoft boccia l’utilizzo di iPerf3 in Windows per il monitoraggio della rete per via delle versioni compilate per Windows basate su Cygwin, che introducono un livello di compatibilità con le API POSIX. Microsoft sottolinea che tale implementazione può alterare le prestazioni e non rappresentare fedelmente il comportamento delle applicazioni Windows native.

Redmond suggerisce quindi NTTTCP e ctsTraffic come strumenti più appropriati per la verifica delle prestazioni della rete con Windows.

NTTTCP utilizza direttamente le funzionalità di rete del sistema operativo; esiste inoltre un’implementazione Linux, sviluppata separatamente, che permette di eseguire test anche tra Windows e Linux.

Dispositivi coinvolti nel test	Soluzione consigliata
Due PC Windows	NTTTCP per Windows
Due sistemi Linux	iPerf3, semplice da installare
Un PC Windows e un computer Linux	NTTTCP per Windows e NTTTCP-for-Linux
PC Windows e NAS basato su Linux	NTTTCP, se eseguibile sul NAS; altrimenti test alternativi con limiti esplicitati
Un NAS che offre iPerf3 ma non NTTTCP	iPerf3 come verifica orientativa, evitando conclusioni definitive basate soltanto sulla compilazione Windows

Test tra due PC Windows: come utilizzare NTTTCP

Dopo aver estratto i file di NTTTCP, supponiamo di collocare l’eseguibile ntttcp.exe nella cartella C:\Tools\NTTTCP di entrambi i computer. Ipotizziamo inoltre che il computer destinato a ricevere il traffico utilizzi l’indirizzo IP 192.168.1.50 (si può verificare l’indirizzo assegnato digitando ipconfig dalla finestra del Prompt dei comandi).

Dalla finestra del terminale, dopo essersi spostati nella cartella contenente l’eseguibile, si possono impartire i seguenti comandi:

• Sul computer ricevente si esegue: ntttcp -r -m 1,*,192.168.1.50 -t 60
• Sul secondo computer, destinato a inviare il traffico: ntttcp -s -m 1,*,192.168.1.50 -l 128K -t 60

Il parametro -r identifica il ricevente, -s il mittente e -t 60 imposta una durata di 60 secondi. Il parametro -m definisce il numero di connessioni, l’affinità CPU (a quale core o processore logico è assegnata l’esecuzione del programma) e l’indirizzo del ricevente.

Sul computer ricevente bisogna consentire il traffico attraverso Windows Defender Firewall: è possibile autorizzare l’eseguibile per la sola rete privata attendibile, preferibilmente limitando la regola all’indirizzo IP del computer mittente, senza aprire le porte verso Internet.

Una volta terminata la prova, NTTTCP mostra il throughput raggiunto e altre informazioni utili sull’esecuzione.

Ripetere il test con quattro connessioni TCP

Se il primo risultato è significativamente inferiore alla velocità nominale, ha senso ripetere la misura con 4 connessioni parallele:

Sul ricevente: ntttcp -r -m 4,*,192.168.1.50 -t 60

Sul mittente: ntttcp -s -m 4,*,192.168.1.50 -l 128K -t 60

Il confronto aiuta a stabilire se la rete ha capacità disponibile che un singolo flusso non riesce a utilizzare. Se una connessione 10 GbE raggiunge 4 Gbps con un solo flusso e 9 Gbps con quattro flussi, il percorso dimostra di poter sostenere circa 9 Gbps aggregati.

Il problema del singolo flusso potrebbe dipendere dall’elaborazione TCP, dalla distribuzione del carico tra i core o da altri limiti dell’endpoint.

Il test va eseguito anche nella direzione opposta, scambiando i ruoli dei due computer e utilizzando l’indirizzo del nuovo ricevente.

Test tra due computer Linux: iPerf3 è la soluzione più semplice

Se entrambi i computer utilizzano Linux, non è necessario installare NTTTCP. iPerf3 è disponibile direttamente nei repository di Ubuntu, Debian e numerose altre distribuzioni. Su Ubuntu e Debian basta eseguire quanto segue:

sudo apt update
sudo apt install iperf3

Supponiamo che il computer Linux ricevente abbia indirizzo 192.168.1.50. Su tale computer si avvia iPerf3 in modalità server:

iperf3 -s

Sul secondo computer Linux va invece eseguito quanto segue:

iperf3 -c 192.168.1.50 -t 60

Il programma genera traffico TCP per 60 secondi e mostra il throughput medio raggiunto. La porta predefinita utilizzata da iPerf3 è la TCP 5201; se il firewall Linux blocca le connessioni in ingresso, bisogna autorizzare tale porta per il computer mittente. Su un sistema che utilizza UFW, ipotizzando che il mittente abbia indirizzo 192.168.1.60, la sintassi è quella riportata di seguito:

sudo ufw allow from 192.168.1.60 to any port 5201 proto tcp

Misurare le prestazioni con più connessioni parallele

Anche in questo caso, se il primo test restituisse una velocità inferiore alle aspettative, il comando da provare è quello che crea 4 flussi TCP paralleli:

iperf3 -c 192.168.1.50 -t 60 -P 4

Il confronto tra i due risultati consente di distinguere un possibile limite del singolo flusso dalla capacità complessiva della connessione. Dalla versione 3.16, iPerf3 utilizza thread separati per i diversi flussi, una caratteristica importante per sfruttare più core quando l’elaborazione del traffico rappresenta un limite.

Per verificare la direzione opposta, senza modificare la modalità del server, è possibile eseguire:

iperf3 -c 192.168.1.50 -t 60 -R

L’opzione -R inverte il verso del traffico: sarà il server a inviare i dati e il client a riceverli.

Se il test standard raggiunge 9 Gbps mentre quello inverso si ferma a 3 Gbps, il risultato suggerisce un’asimmetria da approfondire. Potrebbe dipendere dal comportamento delle schede di rete in trasmissione e ricezione, dalle CPU, dai driver o da altre differenze tra i due endpoint.

Come leggere i risultati: il confronto che individua il collo di bottiglia

Arrivati a questo punto dovremmo avere almeno tre informazioni: velocità negoziata, throughput TCP e velocità di copia dei file. È dal confronto che emerge la parte più utile della diagnosi.

Consideriamo un PC Windows con interfaccia 2,5 GbE e un server Linux collegato a una porta della stessa velocità. Windows indica 2,5 Gbps; NTTTCP raggiunge 2,3 Gbps (287,5 MB/s); una copia SMB procede a 110 MB/s. In questo caso il percorso TCP è in grado di trasferire dati a una velocità più che doppia rispetto alla copia SMB osservata.

La rete fisica non è quindi il principale indiziato: occorre verificare cosa accade quando vengono coinvolti file system, dischi e protocollo di condivisione.

Se invece NTTTCP raggiungesse soltanto 930 Mbps, pari a circa 116 MB/s, ci troveremmo davanti a una situazione diversa: il test sintetico e la copia di file producono risultati molto simili. In questa situazione, il limite potrebbe essere un collegamento Gigabit attraversato lungo il percorso, ma anche una CPU sottodimensionata, un driver problematico o un altro componente che impedisce di utilizzare tutta la capacità disponibile.

Nella grafica pubblicata qui sotto, le varie righe rappresentano scenari diagnostici, non equivalenze automatiche tra un risultato e una specifica causa.

Il test TCP è lento: controllare CPU, driver e adattatori di rete

Se NTTTCP e iPerf3 restituiscono valori nettamente inferiori a quelli attesi, anche usando più connessioni parallele, il problema non dipende necessariamente dal cavo.

Una rete 10 GbE richiede ai dispositivi di gestire un volume significativo di pacchetti, interruzioni e operazioni di copia dei dati in memoria. L’elaborazione può essere distribuita tra più core del processore, ma non sempre accade in maniera efficiente.

In Windows si può aprire il Task Manager (CTRL+MAIUSC+ESC), selezionare Prestazioni, quindi CPU. Facendo clic con il tasto destro sul grafico e scegliendo Cambia grafico in, Processori logici, è possibile osservare l’utilizzo dei singoli processori logici.

Una CPU a 8 core può infatti mostrare un utilizzo totale relativamente basso anche quando un singolo thread sta saturando completamente uno dei core.

Su Linux si può utilizzare il comando top: premendo 1 appare l’utilizzo dei singoli processori logici. Se durante il test TCP un core rimane costantemente saturo, mentre la velocità si ferma molto al di sotto delle capacità della rete, è ragionevole sospettare un limite di elaborazione. Il sospetto diventa più concreto se il throughput aumenta passando da una a 4 connessioni TCP.

Controllare RSS e le funzionalità di offload in Windows

Una delle tecnologie più importanti per le schede Ethernet multi-gigabit è RSS, acronimo di Receive Side Scaling.

RSS permette di distribuire l’elaborazione del traffico ricevuto tra più processori logici, evitando che tutte le operazioni gravino su un unico core. Per verificare le impostazioni RSS in Windows, si può ricorrere alla seguente cmdlet PowerShell:

Get-NetAdapterRss

Per visualizzare le proprietà avanzate della scheda (sostituire Ethernet con il nome effettivo dell’interfaccia):

Get-NetAdapterAdvancedProperty -Name "Ethernet"

Tra le funzionalità da prendere in considerazione figurano RSS, Large Send Offload (LSO), Receive Segment Coalescing (RSC) e checksum offload. Le ultime tre permettono, in modi differenti, di delegare alla scheda di rete parte dell’elaborazione dei pacchetti o di ridurre il numero di operazioni gestite dalla CPU.

Se si sospetta un problema del driver, la priorità dovrebbe essere verificare la disponibilità di aggiornamenti dal produttore della scheda e confrontare i risultati prima e dopo l’intervento.

Controllare il collegamento USB o PCIe

Un adattatore Ethernet USB da 2,5 Gbps collegato a una porta USB 2.0 non può sfruttare tutta la propria velocità, anche se la connessione Ethernet risulta negoziata a 2,5 Gbps. La porta USB 2.0 High Speed ha una capacità nominale di 480 Mbps, insufficiente per trasportare 2,5 Gbps di traffico.

Per gli adattatori multi-gigabit occorre verificare che la connessione USB supporti una velocità adeguata e che eventuali hub o dock non introducano limitazioni.

Un test significativo consiste nel collegare l’adattatore direttamente a una porta USB del computer ad alta velocità (ex SuperSpeed quindi da almeno 5 Gbps o più), escludendo temporaneamente dock e hub.

Per le schede PCIe è invece importante controllare il numero di linee disponibili, la generazione PCIe effettivamente negoziata e l’eventuale condivisione delle risorse.

Una scheda 10 GbE installata in uno slot con banda insufficiente potrebbe non riuscire a raggiungere le prestazioni attese, indipendentemente dalla qualità del collegamento Ethernet.

Il test TCP è lento e irregolare: controllare cavi, errori e switch

Se la velocità oscilla sensibilmente durante il test, oppure si rilevano frequenti ritrasmissioni TCP, è opportuno verificare il livello fisico. Le cause possono essere differenti: cablaggio difettoso, connettori deteriorati, problemi di negoziazione, transceiver, driver e congestione dello switch. Un collegamento Ethernet può rimanere attivo alla velocità nominale anche quando si verificano errori che richiedono ritrasmissioni a livello TCP.

Lato Windows, si può effettuare una prima verifica con il seguente comando PowerShell:

Get-NetAdapterStatistics -Name "Ethernet" | Format-List

Il comando visualizza le statistiche che Windows e il driver rendono disponibili, tra cui contatori relativi a pacchetti e scarti, se supportati. Non tutte le schede espongono gli errori CRC o le informazioni di livello fisico attraverso questa interfaccia.

Su Linux si può invece utilizzare il comando seguente:

ip -s link show enp3s0

Per ottenere statistiche più dettagliate dal driver:

sudo ethtool -S enp3s0

Tra le informazioni più interessanti ci sono i contatori di errori RX/TX, i pacchetti scartati e gli errori CRC o FCS, se disponibili. La presenza di valori superiori a zero non indica un problema: è soprattutto l’aumento durante il test a essere significativo. Se gli errori aumentano sensibilmente sotto carico, vale la pena sostituire temporaneamente il cavo Ethernet e ripetere la stessa prova.

Cat 5e, Cat 6 o Cat 6A: serve davvero cambiare cavo?

Come raccontiamo nell’articolo sulla scelta dei corretti cavi Ethernet, per 2,5 GbE e 5 GbE lo standard IEEE 802.3bz permette di utilizzare cablaggi Cat 5e conformi alle specifiche, entro le distanze previste.

Per 10GBASE-T le condizioni diventano più impegnative: Cat 6A è la scelta progettata per supportare collegamenti fino a 100 metri, mentre con Cat 6 la distanza ammissibile dipende anche dalle condizioni di installazione e dalle interferenze.

Prima di intervenire sull’intero impianto, il test più ragionevole consiste nell’utilizzare un cavo corto e affidabile, verificando se le prestazioni migliorano. Se i risultati rimangono invariati, il cablaggio diventa un indiziato meno evidente e conviene esaminare le altre componenti.

Come capire se è lo switch a rallentare

Per verificare il ruolo dello switch si possono confrontare due configurazioni:

1. Nella prima, i dispositivi utilizzano il normale percorso di rete.
2. Nella seconda, quando le interfacce e l’ambiente lo consentono, sono collegati direttamente tramite Ethernet e configurati con indirizzi IP statici appartenenti alla stessa sottorete.

Ad esempio, si possono assegnare 192.168.50.1/24 e 192.168.50.2/24 alle interfacce utilizzate esclusivamente per il test. Non è necessario un cavo crossover con le moderne interfacce Ethernet dotate di Auto MDI-X.

Se il throughput migliora nettamente nel collegamento diretto, il problema potrebbe essere associato allo switch, alle sue porte, ai cavi precedentemente utilizzati o alla configurazione di rete. Se rimane identico, conviene concentrare l’attenzione sui singoli dispositivi (endpoint).

Il test TCP è veloce ma i file si copiano lentamente: controllare prima i dischi

Supponiamo che una connessione 10 GbE raggiunga 9,2 Gbps con NTTTCP, ma il trasferimento verso un NAS proceda stabilmente a 180 MB/s.

Il collegamento ha dimostrato di poter trasferire dati a una velocità equivalente a circa 1.150 MB/s; la copia dei file sfrutta quindi solo una frazione della capacità disponibile. Il problema potrebbe essere nel sottosistema di storage.

Un singolo hard disk meccanico può raggiungere velocità sequenziali nell’ordine di 150-250 MB/s, con ampie variazioni legate al modello e alle condizioni operative. È quindi perfettamente possibile che un NAS dotato di un solo disco fisso trasferisca dati a 180 MB/s pur essendo collegato a una porta 10 GbE funzionante.

Anche un sistema RAID non garantisce automaticamente la saturazione di una connessione 10 Gbps: le prestazioni dipendono dal numero di unità, dal livello RAID, dalla dimensione delle operazioni, dalla cache e dall’eventuale attività di ricostruzione. Per individuare il limite bisogna osservare le prestazioni dei dischi durante la copia.

Su Windows si possono utilizzare il Task Manager e Monitoraggio risorse, avviabile con premendo Windows+R quindi digitando resmon.

Su Linux, dopo aver installato sysstat se necessario, si può invece impartire il comando iostat -xz 1 che consente di osservare throughput, tempi di attesa, utilizzo e altre statistiche delle unità.

Se durante la copia i dischi del server mostrano un’attività intensa e il throughput di scrittura coincide approssimativamente con la velocità del trasferimento, abbiamo un indizio concreto che il limite sia lo storage.

Il NAS è veloce all’inizio e rallenta dopo pochi secondi

Un altro comportamento frequente riguarda i trasferimenti che partono a velocità molto elevate, per poi stabilizzarsi su valori inferiori. Un file può inizialmente essere copiato a 700 MB/s e, dopo qualche gigabyte, scendere a 150 MB/s.

Una possibile spiegazione è l’utilizzo di una cache veloce: il NAS potrebbe ricevere temporaneamente i dati in RAM o su SSD prima di trasferirli alle unità definitive. Quando la cache raggiunge il proprio limite, la velocità osservata comincia a riflettere le prestazioni sostenute dei dischi.

Un fenomeno simile può verificarsi con SSD che sfruttano una cache SLC. Per eseguire una prova significativa bisogna utilizzare un file sufficientemente grande, prolungare il trasferimento e osservare il comportamento delle unità.

I dischi sono veloci, ma le copie SMB restano lente: cosa verificare

Se NTTTCP indica un throughput elevato e il sottosistema di archiviazione è in grado di sostenere le velocità richieste, il passo successivo riguarda il protocollo di condivisione. SMB (Server Message Block) è utilizzato da Windows e da molti NAS per consentire l’accesso ai file attraverso la rete.

SMB Multichannel permette di utilizzare più connessioni TCP per una sessione SMB quando client, server e configurazione lo supportano. La funzionalità può contribuire a sfruttare più interfacce di rete oppure a distribuire l’elaborazione tra diversi core della CPU su interfacce compatibili con RSS. Per controllare se la funzione è abilitata:

Get-SmbClientConfiguration | Select-Object EnableMultichannel

Il seguente comando permette invece di esaminare le connessioni effettivamente utilizzate e va eseguito mentre è in corso una copia di file sufficientemente lunga:

Get-SmbMultichannelConnection

Un altro controllo utile riguarda le caratteristiche delle connessioni SMB attive:

Get-SmbConnection | Select-Object ServerName, ShareName, Dialect, Signed, Encrypted

L’indicazione Dialect esprime la versione SMB negoziata; le altre informazioni permettono, quando disponibili, di verificare l’utilizzo di firma e cifratura. Sono funzionalità che possono introdurre un costo elaborativo, soprattutto sui dispositivi meno potenti, ma che contribuiscono alla sicurezza delle comunicazioni.

Un file grande si copia velocemente, mille file piccoli no

Se la copia di un singolo archivio da 20 GB procede a velocità elevata, mentre una cartella contenente migliaia di piccoli file richiede molto più tempo, il collo di bottiglia potrebbe non essere la banda di rete. Ogni file richiede operazioni di apertura, gestione dei metadati e scrittura: il costo cumulativo può diventare importante, specialmente quando il dispositivo di destinazione utilizza dischi meccanici.

Anche i controlli antivirus e le funzionalità di scansione in tempo reale possono incidere sulle prestazioni.

Un test utile consiste nel confrontare il tempo necessario per copiare un singolo archivio con quello richiesto per trasferire i file che contiene, osservando contemporaneamente CPU e attività disco.

La differenza non dimostra da sola quale componente sia responsabile, ma indirizza la diagnosi verso le operazioni sui file piuttosto che verso la capacità nominale della connessione Ethernet.

Jumbo Frame e MTU 9000: conviene modificarli?

Quando una rete 10 GbE risulta lenta, uno dei suggerimenti più frequenti consiste nell’attivare i Jumbo Frame. L’idea è aumentare la dimensione dei pacchetti trasportati, riducendo il numero di operazioni necessarie per trasferire una determinata quantità di dati.

In una normale configurazione Ethernet il parametro MTU IP è pari a 1.500 byte; alcune reti permettono di portarla a circa 9.000 byte. Il beneficio può essere concreto in configurazioni specifiche, ma non è garantito. Le schede moderne utilizzano già funzionalità di offload che contribuiscono a ridurre il lavoro della CPU. Inoltre, per utilizzare correttamente pacchetti più grandi, tutte le interfacce interessate e gli apparati intermedi devono supportarli.

Su Windows si può verificare la MTU con:

Get-NetIPInterface | Select-Object InterfaceAlias, AddressFamily, NlMtu

Su Linux, è possibile usare il comando che segue:

ip link show

Per una diagnosi, il consiglio è mantenere la MTU standard e verificare prima le prestazioni con NTTTCP o iPerf3. Soltanto quando si è accertato che il collegamento funziona correttamente, e si dispone di un motivo tecnico preciso, ha senso sperimentare una diversa configurazione MTU.

In conclusione

Un metodo pratico per individuare il collo di bottiglia senza procedere per tentativi consiste nell’effettuare una serie di controlli, che riassumiamo nella grafica sotto.

Il primo controllo consiste sempre nell’esaminare la velocità negoziata dalle schede Ethernet. Se è inferiore al previsto, bisogna verificare prima di tutto porte, cavi e dispositivi intermedi.

Quando la negoziazione è corretta, si misura il throughput tra i due computer con NTTTCP oppure iPerf3, a seconda dei sistemi operativi coinvolti.

Se il throughput è inferiore alle attese, il test va ripetuto in direzione opposta e con più connessioni parallele. Contemporaneamente bisogna osservare il comportamento della CPU.

Se le prove evidenziano una capacità aggregata elevata ma prestazioni ridotte per il singolo flusso, occorre esaminare l’elaborazione TCP, RSS e le funzionalità offerte dai driver. Se invece anche più flussi producono risultati scadenti, è necessario approfondire gli errori di trasmissione, il percorso fisico, gli adattatori e lo switch.

Quando il throughput TCP è elevato ma la copia dei file rimane lenta, la verifica deve spostarsi sullo storage e sul protocollo SMB.