Zum Thema JumboFrames:
JF bringen bei GBit in der Praxis eigenlich nur eine Verringerung der CPU-Last. Performancegewinne (wenn es mit aktueller Hardware noch welche gibt), bewegen sich im Promillebereich:
Code: Alles auswählen
# netperf -H 10.50.50.1 -t TCP_STREAM -C -c -l 60 -- -m 1472
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.50.50.1 () port 0 AF_INET : histogram : interval : dirty data : demo
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % C % C us/KB us/KB
65536 32768 1472 60.01 989.50 12.27 2.20 4.064 1.456
# netperf -H 10.50.50.1 -t TCP_STREAM -C -c -l 60 -- -m 8972
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.50.50.1 () port 0 AF_INET : histogram : interval : dirty data : demo
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % C % C us/KB us/KB
65536 32768 8972 60.03 989.52 9.76 1.45 3.232 0.961
989.50 -> 989.52 MBit/s; das geht als Messtoleranz durch...
Der Benchmark lief im (priorisierten) mgmt-VLAN vom Client (i7 6700, Intel PRO/1000 Onboard) über 2x cisco SG300 mit 2xGBit Uplink zum Gateway (Xeon L5410, Intel PRO/1000). OS an beiden Enden ist FreeBSD; 12-CURRENT bzw TrueOS am Client und 10.3-RELEASE am Gateway.
Einziger unterschied ist die 2.5% höhere CPU-Last mit der kleinen Framegröße - Für ein CPU-schwaches Gateway in einem größeren Netz kann das durchaus einen Unterschied machen; rein aus Sicht der Performance speziell im Heimgebrauch sind JF komplett zu vernachlässigen wenn man mit halbwegs brauchbarer Hardware arbeitet.
Für Subnetze in denen SIP-Geräte sind macht man sich meist mit JF mehr Probleme, da durch die path MTU discovery oft die Latenzen zu stark erhöht werden. Alte SIP-Endgeräte steigen auch gerne einfach aus, billige Switches fangen mit JF auch gerne an Pakete zu droppen - Netgear ist hier mal wieder der notorische Klassendepp (ProSafe....)
Wenn man eher fragwürdige Hardware im "normalen" Heimnetz betreibt würde ich JF einfach ignorieren und bei 1500 Byte MTU bleiben - macht am wenigsten Aufwand und man lädt keine Gremlins ein. In Verbindung mit WLAN ist die MTU sowieso nochmal ein ganz anderes Biest; da hilft meistens nur (viel) testen und benchmarken wenn man an der MTU schrauben will.
In Netzen/VLANs in denen nur Server/Infrastruktur-Geräte kommunizieren und über die auch Backups laufen, habe ich i.d.R. eine MTU von 9000 gesetzt. Hier überwiegt ganz klar der Vorteil der niedrigeren CPU-Last.
Interfaces die von Clients angesprochen werden (also im LAN oder DMZ), haben i.d.R. eine MTU von 1500 gesetzt. Hier werden sowieso praktisch nur Windowskisten bedient und diese Büchse der Pandora öffne ich sicher nicht indem ich an denen ne höhere MTU setze, speziell da hier Hardware aus allen Preisklassen bis ~10 Jahre alter vorhanden ist...
Am WAN ist man meist durch den ISP beschnitten - oft sogar auf (deutlich) <1500 Byte. Bei FTTH-Anschlüssen oder regionalen Netzbetreibern kann man immer öfter auch mit höherer MTU fahren - das macht vor allem dann Sinn, wenn der ISP z.B. cache-/accelerator-/CDN-appliances im eigenen Netz hat (z.B. von Netflix, cloudflare, akamai, google...).