MokerLink 2G080110GS benchmark: 941 Mbps, zero retransmit e il vero collo di bottiglia del mio homelab

Mini PC homelab 2026: quale tieni acceso 24/7 senza rimpianti

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.

Setup: cluster Proxmox + MokerLink 2G080110GS benchmark

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).

Latenza e TCP single stream: i numeri del benchmark iperf3 Proxmox

Latenza ICMP: 0.124 ms di media, zero pacchetti persi

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 ms

0.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.

TCP single stream: line rate con 0 retransmit

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

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.

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 Gbps

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.

UDP stress test: 0 pacchetti persi su 820.176

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.

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.

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