12 aprile 2026 · 6 min lettura
GuideOgni prodotto che entra nel nostro lab passa per 4 fasi di benchmark. iperf3 è lo strumento che usiamo
HardwareQuanto hardware serve per pareggiare i free tier di ChatGPT, Claude e Gemini con un LLM locale? Ho fatto i conti: GPU, VRAM, elettricità, break-even.
HardwareIscriviti alla newsletter per ricevere i migliori articoli direttamente nella tua inbox.
Beelink, Minisforum e GMKtec a confronto per homelab Proxmox e Ollama. Chi gestisce meglio VM, inference AI e NAS con 10-20W di consumo nel 2026.
941 Mbps. 0 retransmit. 0% packet loss. Questi sono i numeri del MokerLink 2G080110GS benchmark homelab eseguito il 12 aprile 2026 sul mio cluster Proxmox. Tre varianti di test diverse, stesso risultato: line rate 1GbE raggiunto ogni volta, senza un singolo pacchetto perso. Lo switch è da 79.99 dollari. Il collo di bottiglia non è lui — è la NIC.
Ne avevo già parlato nell'unboxing del MokerLink 2G080110GS — 8 porte 2.5GbE + 1 SFP+ 10G, chip Realtek RTL8373, qualità costruttiva sopra le aspettative per il prezzo. Ma un unboxing non dice niente sulla performance reale. I numeri arrivano dopo. Eccoli.
Due nodi Proxmox collegati direttamente allo switch, bridge vmbr0 su entrambi, MTU 1500 standard. Nessun middlebox in mezzo. Tool: iperf3 v3.18 e ping (iputils).
| Parametro | pve1 (principale) | pve2 (failover) |
|---|---|---|
| CPU | AMD Ryzen 7 1800X (8C/16T) | AMD Ryzen 3 3200G (4C/4T) |
| RAM | 47 GB | 12 GB |
| NIC | Realtek RTL8125 2.5GbE | Realtek RTL8111 1GbE |
| Ruolo | 14+ container LXC attivi | Failover + replica ZFS ogni 30 min |

ping -c 50 -i 0.1 10.x.x.A
# 50 packets transmitted, 50 received, 0% packet loss
# rtt min/avg/max/mdev = 0.084/0.124/0.174/0.023 ms0.124 ms di media, 0.084 ms di minimo. Per una LAN switched con hardware consumer da 79.99$, sono numeri da commutatore enterprise. Il mdev di 0.023 ms indica jitter praticamente assente — il timing dei pacchetti è stabile anche sotto carico.
iperf3 -c 10.x.x.A -t 30 --json
# Sender (pve2): 3.53 GB — 941.86 Mbps — 0 retransmit
# Receiver (pve1): 941.28 Mbps
# TCP RTT: min 1071 µs / mean 1375 µs / max 1710 µs
# CPU sender (pve2): 2.82% | CPU receiver (pve1): 45.63%941.86 Mbps con 0 retransmit. Il link 1GbE è saturo al 94.2% della capacità nominale — è tutto quello che si può ottenere con overhead TCP/IP standard. Lo switch introduce meno di 1 Mbps di perdita tra sender e receiver (941.86 vs 941.28): trascurabile.
Quello che invece colpisce è il CPU del receiver: 45.63% su pve1 per ricevere un singolo stream TCP. Il sender pve2 usa solo 2.82%. Tornerò su questo — è il dato più importante dell'intero test.
I 4 stream paralleli non guadagnano nulla rispetto a uno solo: il link è già saturo. La simmetria upload/download (941 vs 943 Mbps) conferma che lo switch gestisce entrambe le direzioni senza asimmetrie hardware.
Il test bidirezionale è quello più vicino al traffico reale di un cluster HA: replica ZFS in un senso, traffico container nell'altro, contemporaneamente.
iperf3 -c 10.x.x.A -t 10 --bidir
# TX (pve2→pve1): 921 Mbps — 1 retransmit
# RX (pve1→pve2): 707 Mbps — 494 retransmit
# Aggregato: ~1.6 GbpsIn trasmissione siamo ancora a 921 Mbps con 1 solo retransmit. In ricezione il throughput scende a 707 Mbps con 494 retransmit. L'asimmetria non è dello switch: è l'effetto classico di due stream che si contendono la stessa NIC 1GbE di pve2 in full duplex. Il totale aggregato è ~1.6 Gbps, che su un link fisico da 1G significa entrambi i sensi al quasi-massimo possibile.
iperf3 -c 10.x.x.A -t 10 -u -b 950M
# Bitrate: 950 Mbps
# Jitter: 0.014 ms (14 µs)
# Packet loss: 0/820176 (0.0%)820.176 pacchetti inviati. Zero persi. Jitter di 14 microsecondi.
UDP è il test più duro per uno switch consumer: nessun controllo di flusso, rate fisso, il buffer deve reggere senza scartare un frame. Uno switch unmanaged da 79.99$ che gestisce 950 Mbps UDP con jitter a 0.014 ms — qualsiasi workload real-time passa su questo switch senza problemi.
Devo fare una confessione homelab.
Quando ho visto il 45.63% di CPU su pve1 nel test TCP single stream, ho pensato a un errore di misurazione. Ho rifatto il test. Stesso risultato. Breakdown: 1.10% user, 44.53% system. Tutta CPU kernel, non applicativa. Il driver r8169 che gestisce la RTL8125 su pve1 non è offload-friendly: con 941 Mbps il kernel lavora duramente per processare gli interrupt di rete. Il sender pve2 con la sua RTL8111 più vecchia usa solo il 2.82%. Ironia: la NIC più moderna brucia più cicli CPU per gestirla.
Il punto interessante: con l'upgrade di pve2 a 2.5GbE, il link salirà a 2.5G e a parità di throughput ci saranno meno frame da processare per unità di tempo. In teoria la CPU dovrebbe scendere nonostante il maggior bitrate — lo verificherò nel Part 2. Per chi vuole la metodologia di test completa, c'è la guida benchmark iperf3 per homelab con tutti i parametri, le ripetizioni e come interpretare i percentili RTT.
Il cluster — di cui ho descritto l'architettura completa nell'anatomia del cluster Proxmox a 14 container — gira Proxmox HA con stack di monitoring, IDS e automazione di sicurezza attivi. Non è un setup leggero. In questo contesto, 941 Mbps con 0 retransmit significa che la replica ZFS non è mai il collo di bottiglia della rete: a 117 MB/s il throughput di rete è più che sufficiente per la replica. Il limite reale della replica ZFS è la latency e le scritture random sull'SSD, non il throughput sequenziale di rete.

Il piano per il Part 2: scheda PCIe 2.5GbE su pve2 (~15-20€, chip Intel I225 o RTL8125), jumbo frames MTU 9000 su entrambi i nodi, poi benchmark completo con gli stessi test. La porta SFP+ 10G del MokerLink resta da testare — servirà un modulo DAC e un peer 10G, tema per un futuro Part 3.
Uno switch da 79.99$ che gestisce 941 Mbps TCP e 820.176 pacchetti UDP senza perderne uno. Il bottleneck sei tu — o meglio, la NIC del tuo nodo failover.
Fonti: benchmark iperf3 v3.18 eseguito il 12/04/2026 · MokerLink 2G080110GS unboxing · guida benchmark iperf3 homelab
| Test | Throughput Sender | Throughput Receiver | Retransmit |
|---|---|---|---|
| TCP single stream (30s) | 941.86 Mbps | 941.28 Mbps | 0 |
| TCP 4 stream paralleli (15s) | 942.93 Mbps | 941.08 Mbps | 0 |
| TCP reverse/download (15s) | 943.57 Mbps | 941.42 Mbps | 0 |
| Scenario homelab | Situazione attuale (1GbE) | Con upgrade 2.5GbE |
|---|---|---|
| Replica ZFS ogni 30 min | Link saturato durante sync | 2.5× headroom, sync più rapida |
| HA bidir + container | Contesa NIC pve2 in full duplex | Link fisico meno congestionato |
| CPU pve1 durante trasferimento | 45% system (impatta container) | Stimata riduzione — da verificare Part 2 |
| Latenza container-to-container | 0.124 ms RTT (eccellente) | Invariata — dipende da switch, non da NIC speed |