Trasparenza: MokerLink è sponsor di homelabz e mi ha fornito lo switch qui testato. Giudizio e numeri sono miei, basati sull'uso reale.
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).
MokerLink 2G080110GS benchmark Part 2: da 941 Mbps a 2.36 Gbps — upgrade NIC e test reali a 2.5GbE
Nel Part 1 avevamo raggiunto 941 Mbps con 0 retransmit e concluso che il collo di bottiglia non era lo switch MokerLink da 79.99 dollari — era la NIC 1GbE di pve2. Oggi la NIC è stata sostituita con una Realtek RTL8125 2.5GbE su entrambi i nodi del cluster Proxmox. Stessi test, s
pve2 (failover)
16 GB
ParametroNIC
pve1 (principale)Realtek RTL8125 2.5GbE
pve2 (failover)Realtek RTL8111 1GbE
ParametroRuolo
pve1 (principale)14+ container LXC attivi
pve2 (failover)Failover + replica ZFS ogni 30 min
Parametro
pve1 (principale)
pve2 (failover)
CPU
AMD Ryzen 7 1800X (8C/16T)
Intel Core i7-6700K (4C/8T)
RAM
47 GB
16 GB
NIC
Realtek RTL8125 2.5GbE
Realtek RTL8111 1GbE
Ruolo
14+ container LXC attivi
Failover + replica ZFS ogni 30 min
MokerLink 2G080110GS: 8 porte 2.5GbE + 1 SFP+ 10G — il protagonista del benchmark. Foto: homelabz.cc
Latenza e TCP single stream: i numeri del benchmark iperf3 Proxmox
Latenza ICMP: 0.124 ms di media, zero pacchetti persi
0.124 ms di media, 0.084 ms di minimo. Per una LAN switched con hardware consumer da 79.99$, sono numeri da switch enterprise. Il mdev di 0.023 ms indica jitter praticamente assente — il timing dei pacchetti è stabile anche sotto carico.
TCP single stream: line rate con 0 retransmit
bash
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.
4 stream paralleli e reverse: simmetria perfetta
TestTCP single stream (30s)
Throughput Sender941.86 Mbps
Throughput Receiver941.28 Mbps
Retransmit0
TestTCP 4 stream paralleli (15s)
Throughput Sender942.93 Mbps
Throughput Receiver941.08 Mbps
Retransmit0
TestTCP reverse/download (15s)
Throughput Sender943.57 Mbps
Throughput Receiver941.42 Mbps
Retransmit0
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
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.
Full duplex e UDP: dove il switch 2.5G homelab viene davvero stressato
Il test bidirezionale è quello più vicino al traffico reale di un cluster HA: replica ZFS in un senso, traffico container nell'altro, contemporaneamente.
In 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.
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.
Il dato che nessuno guarda: 45% CPU per ricevere traffico TCP
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.
Implicazioni pratiche e Part 2: cosa cambia con 2.5GbE
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.
Scenario homelabReplica ZFS ogni 30 min
Situazione attuale (1GbE)Link saturato durante sync
Con upgrade 2.5GbE2.5× headroom, sync più rapida
Scenario homelabHA bidir + container
Situazione attuale (1GbE)Contesa NIC pve2 in full duplex
Con upgrade 2.5GbELink fisico meno congestionato
Scenario homelabCPU pve1 durante trasferimento
Situazione attuale (1GbE)45% system (impatta container)
Con upgrade 2.5GbEStimata riduzione — da verificare Part 2
Scenario homelabLatenza container-to-container
Situazione attuale (1GbE)0.124 ms RTT (eccellente)
Con upgrade 2.5GbEInvariata — dipende da switch, non da NIC speed
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
La porta SFP+ 10G: non ancora testata, servirà un modulo DAC e un peer 10G. Per ora resta in attesa. Foto: homelabz.cc
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.
