Ogni prodotto che passa dal nostro lab affronta almeno 4 fasi di benchmark di rete prima che un singolo numero finisca in una review. TCP throughput, UDP jitter, VM-to-VM, throughput applicativo. Quattro misurazioni diverse, con flag specifici, ripetute in entrambe le direzioni. Lo strumento che usiamo per le prime tre è sempre lo stesso: iperf3 homelab. Ecco perché, ecco come, e — soprattutto — ecco cosa sappiamo che non misura.
Perché iperf3 è il nostro standard homelab
iperf3 è mantenuto da ESnet (Energy Sciences Network), il backbone di rete del Dipartimento dell'Energia statunitense — la stessa infrastruttura che connette i laboratori nazionali come Fermilab e SLAC. Non è un progetto hobby. La versione 3.21, rilasciata il 9 aprile 2026, introduce supporto GSO/GRO su Linux per migliorare le performance su NIC ad alta velocità.
Tre ragioni concrete per cui lo abbiamo scelto come strumento primario:
Output JSON nativo (-J) — ogni test finisce in un file strutturato che possiamo confrontare nel tempo, parsare con script, o importare in Grafana
Zero-copy mode (-Z) — riduce il carico CPU sul client, isolando il collo di bottiglia sulla rete anziché sul processore
Multi-threading reale da v3.16 (dicembre 2023) — i parallel stream (-P) girano finalmente su core separati, eliminando il bottleneck single-threaded che affliggeva le versioni precedenti
Open source, multipiattaforma (Linux, macOS, FreeBSD), con un'API libreria che permette integrazione in tool di automazione. Per il contesto homelab è lo strumento più documentato: qualsiasi guida su switch 2.5G, NAS, o VPN come NetBird usa iperf3 come riferimento. Noi compresi.
Il nostro setup: un CT dedicato su Proxmox
Nel nostro lab Proxmox gira un container LXC Alpine dedicato esclusivamente a iperf3. Niente altro sopra — nessun servizio che possa competere per CPU o banda. Il server iperf3 è sempre attivo via systemd sulla porta 5201.
RuntimeMaxSec=3600 forza il restart ogni ora — una precauzione contro memory leak nei test prolungati. Il container è connesso al bridge principale (vmbr0) con VirtIO e MTU 1500 standard. Quando testiamo jumbo frames, cambiamo MTU esplicitamente e lo documentiamo.
Iscriviti alla newsletter per ricevere i migliori articoli direttamente nella tua inbox.
Self-Hosting
Ho centralizzato il login di 14 servizi con Authentik. Avrei dovuto farlo prima.
Quattordici container. Quattordici pagine di login. Quattordici password diverse — o, peggio, la stessa password usata ovunque perché tanto "è roba mia".
Un secondo nodo iperf3 gira su una subnet separata, su un host fisico diverso. Questo ci permette di testare sia il traffico intra-host (VM-to-VM attraverso il bridge) sia il traffico reale che attraversa lo switch fisico.
La metodologia iperf3 homelab in 4 fasi
Questa è la parte che conta. Non il tool — la metodologia. Un numero iperf3 senza contesto è rumore. Ecco esattamente cosa facciamo per ogni prodotto di rete che recensiamo.
Fase 1 — TCP throughput bidirezionale
Il test base. Misuriamo il throughput TCP in upload e download con 4 stream paralleli, 30 secondi di durata, e i primi 3 secondi esclusi dalla media per eliminare il TCP slowstart.
Ogni flag ha un motivo preciso. -P 4 usa 4 stream paralleli — abbastanza per saturare il link senza sovraccaricare la CPU. -O 3 (omit) esclude i primi 3 secondi dalla media: senza questo flag, il TCP slowstart abbassa artificialmente il risultato nei test brevi. -R inverte la direzione: il server trasmette e il client riceve, misurando il throughput in download. -J salva tutto in JSON per analisi successive.
I risultati TCP ci danno la capacità grezza del link. Su uno switch 2.5GbE come il MokerLink ci aspettiamo ~2.36 Gbps (il margine rispetto ai 2.5 Gbps nominali è fisiologico — overhead Ethernet, TCP/IP headers). Se il numero è significativamente inferiore, il problema è altrove: driver NIC, buffer TCP, configurazione dell'host.
Fase 2 — UDP jitter e packet loss
Il TCP è gentile: ritrasmette i pacchetti persi, rallenta se c'è congestione. L'UDP no. E proprio per questo è utile per scoprire problemi che il TCP nasconde.
bash
# UDP — specificare SEMPRE -b, altrimenti il default è 1 Mbit/sec
iperf3 -c 10.0.1.50 -u -b 2.5G -t 30 -i 1
Il flag -b 2.5G è obbligatorio. Senza specificare il target bandwidth, iperf3 manda solo 1 Mbit/sec in UDP — un test completamente inutile su un link da 2.5 Gbps, ma un errore che vediamo ripetuto in decine di guide online.
Le soglie che usiamo per valutare i risultati:
MetricaJitter
Buono< 1 ms
Accettabile1-5 ms
Problema> 5 ms
MetricaPacket loss
Buono< 0.1%
Accettabile0.1-1%
Problema> 1%
Metrica
Buono
Accettabile
Problema
Jitter
< 1 ms
1-5 ms
> 5 ms
Packet loss
< 0.1%
0.1-1%
> 1%
Packet loss sopra l'1% impatta VoIP e real-time streaming. Sopra il 5% è un problema serio. Un jitter sotto i 5 ms è accettabile per la maggior parte degli use case homelab; sotto 1 ms è eccellente.
Fase 3 — VM-to-VM e VPN overhead con iperf3
Qui iperf3 homelab diventa davvero interessante. Non testiamo solo il link fisico — testiamo l'intera catena: hypervisor, bridge virtuale, NIC virtuale, VPN tunnel.
Proxmox VM-to-VM sullo stesso host con Linux bridge e VirtIO può raggiungere 17-25 Gbps — molto più della velocità del link fisico, perché il traffico non esce mai dall'host. È un dato utile per capire l'overhead del bridge. Tra host diversi con MTU 1500 standard ci aspettiamo 1-2.5 Gbps; con jumbo frames (MTU 9000) si arriva a 9-10 Gbps su link 10G.
Per le VPN, il pattern è semplice: misuriamo prima senza tunnel, poi con tunnel, e calcoliamo l'overhead percentuale. Su WireGuard con singolo stream: ~600 Mbps con VPN vs ~850 Mbps senza, overhead circa 30%. Con 10 stream paralleli il gap si riduce: ~800 Mbps vs ~900 Mbps, overhead ~11%. La CPU su x86-64 moderno incide in modo minimale.
Fase 4 — Throughput applicativo (dove iperf3 non basta)
Questa è la fase che molti saltano. E non dovrebbero.
iperf3 misura la capacità grezza del link IP. Non il throughput reale di un trasferimento file SMB. Non la velocità di un backup NFS. Non le IOPS di un volume iSCSI. Il pattern "iperf3 ok → SMB lento" è tra i più comuni in homelab: iperf3 mostra 2.36 Gbps su un link 2.5GbE, ma il trasferimento SMB si ferma a 78 MB/s — meno di un quarto di quello che il link potrebbe sostenere.
Quella discrepanza non è un fallimento del test. È informazione. Indica dove si trova il collo di bottiglia reale: buffer TCP del client, driver NIC, configurazione SMB3, overhead del filesystem. Per le nostre review completiamo sempre il quadro con dd/fio via rete e misurazioni SMB/NFS dirette.
Lo stack completo per review di rete:
iperf3 TCP — baseline throughput link layer
dd/fio via rete — throughput applicativo NFS/SMB/iSCSI
ping/mtr — latenza RTT (che iperf3 non misura)
iperf3 UDP con -u -b — jitter e packet loss
Cosa sappiamo e gestiamo
iperf3 ha limitazioni reali. Non le nascondiamo — le conosciamo, e per questo i nostri test sono più affidabili di chi le ignora.
Windows. ESnet non supporta ufficialmente iperf3 su Windows. La versione 3.1.3 disponibile su iperf.fr — ancora la più scaricata — gira tramite emulazione Cygwin e ha un bug che limita il socket buffer a 1 MB. Nei test Microsoft, ntttcp ha raggiunto 12.75 Gbps contro 7.5 Gbps di iperf3 sullo stesso hardware. Noi facciamo girare iperf3 su Linux. Sempre. Se un dispositivo richiede test da Windows, usiamo ntttcp o iperf2.
Jitter UDP. iperf3 calcola il jitter secondo RFC 1889, ma con un difetto noto: inizia da 0 (valore artificialmente basso) e in caso di gap nella sequenza prosegue senza reset (valore artificialmente alto). Ne siamo consapevoli, e per questo interpretiamo i valori di jitter come indicativi — non come misurazioni assolute. Per chi necessita jitter UDP preciso, rperf (scritto in Rust) è più accurato.
Un client alla volta. iperf3 accetta una sola connessione client per istanza server. Per test multi-client lanciamo più istanze su porte diverse (5201, 5202...). Su link 40G/100G è l'unico modo per saturare realmente la banda.
Ho scoperto il problema del flag -P nel modo peggiore: durante un benchmark per una review, i numeri non tornavano. Lo switch prometteva throughput 2.5G non-blocking, ma iperf3 restituiva risultati inconsistenti — a volte 2.3 Gbps, a volte 600 Mbps. Stesso hardware, stesso cavo, stessa ora. Ho passato due ore a cambiare cavi e porte prima di trovare il colpevole: avevo -P 4 prima di -c nel comando. Un flag nell'ordine sbagliato. Risultati fino a 4x più bassi. Da quel giorno, ogni comando iperf3 nelle nostre review segue un template verificato.
Cosa significa per voi
Per i lettori: quando vedete un numero di throughput nelle nostre review, quel numero ha dietro una metodologia specifica. Sapete che abbiamo usato -O 3 per escludere il slowstart. Sapete che abbiamo testato in entrambe le direzioni. Sapete che abbiamo confrontato il dato iperf3 con il throughput applicativo reale. Non è un numero copiato dal datasheet.
Per i partner: testiamo ogni prodotto con la stessa metodologia. Se il throughput misurato è inferiore al dichiarato, lo riportiamo — ma cerchiamo anche il perché. Spesso il "problema" non è il prodotto ma la configurazione del test. Trasparenza nella metodologia significa review credibili per chi le legge e utili per chi produce.
Ogni numero che pubblichiamo su homelabz.cc ha questa metodologia dietro. Quattro fasi, flag documentati, limitazioni dichiarate. Nessun numero orfano.
