Giga Internet: weniger Speed als vorher

nando4569 · 2019-10-02T09:21:32+00:00

Sunrise Community - Kunden helfen anderen Kunden rund um die Themen Fernsehen, Internet, Telefon und Mobile. Jetzt registrieren!

GrandDixence

In der Theorie sind Verfahren zur Überlastkontrolle und Stausteuerung wie:

- Ethernet Flow Control

- Explicit Congestion Notification (ECN)
https://en.wikipedia.org/wiki/Explicit_Congestion_Notification

https://de.wikipedia.org/wiki/%C3%9Cberlastkontrolle

https://en.wikipedia.org/wiki/Network_congestion

eine gute Sache. Leider hapert es mit der Umsetzung in der Praxis.

ECN verwende ich nicht, da die im Heimnetzwerk eingesetzten Netzwerkkarten offenbar keine Hardwarebeschleunigung (Hardware Offloading) für ECN unterstützen:

tx-tcp-ecn-segmentation: off [fixed]

Die Reduktion der Datenübertragung per verworfene Datenpakete (DROP) über das TCP Receive Window (=> Ausgabe: CWin in den IPerf3-TCP-Messungen) ist die “brachiale” Methode der Stausteuerung. Die oben genannten Methoden sind die “sanften”, fein regulierbaren Methoden der Stausteuerung.

millernet

@GrandDixence Was ist eigentlich deine Meinung zum Thema Ethernet flow control? Ich habe einen guten Blog Post zu diesem Thema gefunden, welche auf Switches eher zur Deaktivierung von flow control rät (http://virtualthreads.blogspot.com/2006/02/beware-ethernet-flow-control.html). Grundsätzlich verfügt ja TCP eigene Mechanismen zur Flusssteuerung und kann von der Ethernet flow control negativ beeinflusst werden, da die pause frames generell für die Schnittstelle gelten resp. für alles > Layer 2. Bei einigen Storage Systemen wird abgeraten, flow control zu aktivieren und lieber die Mechanismen im höheren Stack walten zu lassen. Aber das Thema ist ziemlich kontrovers.

Nun habe ich ethernet flow control ja aktiviert um zu verhindern, dass der Server bei iPerf überfordert wird und der Durchsatz wurde auf ca. 920 Mbit/s durch den Switch mit pause frames heruntergedrosselt. Es gab auch keine TCP retransmission und Retr = 0. Bei deaktiviertem flow control kam es zu vielen retransmissions, aber der Durchsatz lag bei zu erwartetem Gigabit Niveau mit ca. 940 Mbit/s. Durch ethernet flow control wäre ja die komplette NIC vom Switch ausgebremst worden, wenn z.B parallel noch eine zweite Datenübertragung zu einem anderen Server stattgefunden hätte. Insofern darf argumentiert werden, dass TCP by design retransmissions resp. Übertragungsfehler zur Steuerung nutzt.

millernet

Danke für den Hinweis. Der Ryzen 3900x hat auch eine sehr gute Single Core Performance ;-). Der Prozessor isst einen i9-9900K zum Frühstück. Von 30 Giga/s bin ich weit entfernt. Ich kann locker mit 5 Gb/s zwische Workstation und meinem NAS per SMB Daten übertragen und die Prozessorlast ist niedrig. Meine Entschluss steht fest: Der EdgeRouter wird ausgebaut und ich nehme wieder eine virtuelle OPNsense Appliance in Betrieb. Dieses Setup habe ich bisher für 3 Jahre erfolgreich betrieben. Auch hier werde ich natürlich wieder iperf3 Tests machen.

GrandDixence

@millernet schrieb:

Der Client hat ein neuer Build mit Ryzen 3900x mit 12 Kernen….. selbst ohne Offloading sollte Leistung eigentlich kein Problem sein.

Ein Mehrkernprozessor (hier: 12 Kerne/Cores) ist toll und schön. Nur nützt er nichts, wenn die Anwendung nur 1 Kern nutzt. IPerf3 wurde als “Single-Threaded”-Anwendung programmiert und nutzt deshalb von der CPU immer nur 1 Kern für Rechenarbeiten.

Für die Messung von mehreren TCP-Verbindungen gleichzeitig ist die Nutzung von IPerf2 empfohlen. IPerf2 wurde als “Multi-Threaded”-Anwendung programmiert und nutzt gleichzeitig möglichst alle Kerne eines Mehrkernprozessors.

https://fasterdata.es.net/performance-testing/network-troubleshooting-tools/iperf/multi-stream-iperf3/

https://software.es.net/iperf/faq.html

https://github.com/esnet/iperf/issues/289

Damit nicht die CPU-Rechenleistung die Messresultate verfälscht, sollten keine IPerf3-Messungen mit Netzwerkverbindungen > 30 GBit/s durchgeführt werden!

GrandDixence

Mit dem Ausschalten der Auto Negotiation (autoneg off) wird die automatische Aushandlung der für diese Ethernet-Verbindung zu verwendenden Ethernet-Funktionalitäten ausgeschaltet.

Ethernet Flow Control ist eine Ethernet-Funktionalität, welche per Auto Negotiation von den beiden Ethernet-Kommunikationspartnern ausgehandelt wird. Ethernet Flow Control wird erst eingesetzt, wenn beide Ethernet-Kommunikationspartnern diese Funktion unterstützen und deren Anwendung zustimmen. Ist Auto Negotiation auf mindestens einem Ethernet-Kommunikationspartner ausgeschaltet, ist auch Ethernet Flow Control automatisch ausgeschaltet! => Kontrolle dieser Aussage mit dem ethtool-Parameter “–show-pause” oder auf der entsprechenden Ethernet-Statistik-Webseite des Webinterface des Netgear Switches. Siehe auch Beitrag Nr. 120.

Auto Negotiation sollte erfahrungsgemäss nur bei Glasfaser-Ethernet ausgeschaltet werden. Besser als die Ausschaltung von “Auto Negotiation” wäre es, mit dem ethtool-Parameter “–pause” auf dem Linux-Rechner oder im Webinterface des Netgear Switch explizit nur Ethernet Flow Control für den 10 GB-Ethernet-Port auszuschalten. Die Auswirkung auf die IPerf3-Messungen wird identisch sein.

millernet

Das Problem an der AQC107 in TX-Richtung konnte ich mit

sudo ethtool -s enp4s0 speed 1000 duplex full autoneg off

“beheben”. Jetzt läufts auch mit den vollen 941 Mbit/s:

[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-30.00 sec 3.29 GBytes 942 Mbits/sec 0 sender
[ 4] 0.00-30.00 sec 3.29 GBytes 942 Mbits/sec receiver

Offenbar liegt das Problem darin, dass 10 Gigabit/s auf 1 Gigabit/s heruntergedrosselt werden müssen durch den Switch mit aktivem Flow Control. Ist Flow Control nicht aktiv, dann kommt es zur hohen Retr.

millernet

Herzlichen Dank für deine Inputs und Hilfe. Jetzt habe ich den Client über die 10-Giga-NIC (Aquantia AQC107, Asus XG-C100C) angeschlossen und auf dem entsprechenden 10-Giga-Port flow control aktiviert. Jetzt läuft es wie folgt:

Client => GS110EMX => Server:

[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-30.00 sec 3.21 GBytes 920 Mbits/sec 0 sender
[ 4] 0.00-30.00 sec 3.21 GBytes 919 Mbits/sec receiver

Server=> GS110EMX => Client (Revers)

[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-30.00 sec 3.29 GBytes 942 Mbits/sec 0 sender
[ 4] 0.00-30.00 sec 3.29 GBytes 942 Mbits/sec receiver

Damit erachte ich die Flow Control als nützliches Feature und habe es mal auf allen Ports aktiviert. Jetzt hat der Client in TX oder der Server in RX noch eine Limitation. Es wird aber der Client mit der AQC107 sein, da es mit der zweiten NIC des Client (I211) keine Limitation des Durchsatzes gibt. Der Client hat ein neuer Build mit Ryzen 3900x mit 12 Kernen….. selbst ohne Offloading sollte Leistung eigentlich kein Problem sein. Folgender Auszug vom Client von AQC107 (wesentliche Unterschiede zum I211 Fett formatiert):

sudo ethtool –show-offload enp4s0
Features for enp4s0:
rx-checksumming: on
tx-checksumming: on
tx-checksum-ipv4: off [fixed]
tx-checksum-ip-generic: on
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp-mangleid-segmentation: off
tx-tcp6-segmentation: off [fixed]
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: on
rx-vlan-offload: off [fixed]
tx-vlan-offload: off [fixed]
ntuple-filters: off [fixed]
receive-hashing: on
highdma: off [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-gre-csum-segmentation: off [fixed]
tx-ipxip4-segmentation: off [fixed]
tx-ipxip6-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-udp_tnl-csum-segmentation: off [fixed]
tx-gso-partial: off [fixed]
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: off [fixed]
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]

Auszug mit I211:

sudo ethtool –show-offload enp5s0
Features for enp5s0:
rx-checksumming: on
tx-checksumming: on
tx-checksum-ipv4: off [fixed]
tx-checksum-ip-generic: on
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: on
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp-mangleid-segmentation: off
tx-tcp6-segmentation: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: on [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: on
tx-gre-csum-segmentation: on
tx-ipxip4-segmentation: on
tx-ipxip6-segmentation: on
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
tx-gso-partial: on
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: off [fixed]
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]

GrandDixence

@millernet schrieb:

Direkt verbunden läuft der Transfer zwischen Server => Client (Revers) langsamer als über die Switches ?!

Sind Server und Client direkt verbunden, ist Ethernet Flow Control aktiv. Kontrolle dieser Aussage mit:

# su

ethtool –show-pause

Pause parameters for eth0:
Autonegotiate: on
RX: on
TX: on

unter Linux Mint.

Gemäss Bedienungsanleitung Seite 62 des Netgear GS110EMX ist Ethernet Flow Control standardmässig ausgeschaltet.Somit wirkte bei der IPerf3-Messung “Revers, Lokal/ Layer 2 (Server => Netgear GS110EMX => Client)” kein Ethernet Flow Control.

\=> Für mehr Informationen zu Ethernet Flow Control siehe Beitrag Nr. 109.

Ethernet Flow Control auf den betroffenen Ports des Netgear GS110MX einschalten und die IPerf3-Messung “Revers, Lokal/ Layer 2 (Server => Netgear GS110EMX => Client)” wiederholen.

Dank aktivem Ethernet Flow Control wird die gemessene Datenübertragungsrate bei 778 MBit/s liegen und der TCP-Retransmission-Zähler (Retr) wird auf 0 stehen bleiben.

Während dieser IPerf3-Messung werden die entsprechenden Pause-Zähler der Ethernet-Statistik (rx_flow_control_xon und tx_flow_control_xon) hochlaufen:

# su

ethtool –statistics eth0

NIC statistics:
rx_packets: 14177
tx_packets: 7680
rx_bytes: 15637850
tx_bytes: 864083
rx_broadcast: 5
tx_broadcast: 4
rx_multicast: 0
tx_multicast: 6
rx_errors: 0
tx_errors: 0
tx_dropped: 0
multicast: 0
collisions: 0
rx_length_errors: 0
rx_over_errors: 0
rx_crc_errors: 0
rx_frame_errors: 0
rx_no_buffer_count: 0
rx_missed_errors: 0
tx_aborted_errors: 0
tx_carrier_errors: 0
tx_fifo_errors: 0
tx_heartbeat_errors: 0
tx_window_errors: 0
tx_abort_late_coll: 0
tx_deferred_ok: 0
tx_single_coll_ok: 0
tx_multi_coll_ok: 0
tx_timeout_count: 0
tx_restart_queue: 0
rx_long_length_errors: 0
rx_short_length_errors: 0
rx_align_errors: 0
tx_tcp_seg_good: 8
tx_tcp_seg_failed: 0
rx_flow_control_xon: 0
rx_flow_control_xoff: 0
tx_flow_control_xon: 0
tx_flow_control_xoff: 0
rx_csum_offload_good: 14107
rx_csum_offload_errors: 0
rx_header_split: 0
alloc_rx_buff_failed: 0
tx_smbus: 0
rx_smbus: 0
dropped_smbus: 0
rx_dma_failed: 0
tx_dma_failed: 0
rx_hwtstamp_cleared: 0
uncorr_ecc_errors: 0
corr_ecc_errors: 0
tx_hwtstamp_timeouts: 0
tx_hwtstamp_skipped: 0

Wichtig: Der Zähler rx_crc_errors (Checksummen-Fehler der empfangenen Ethernet-Pakete) muss immer auf 0 bleiben. Läuft dieser Zähler hoch, liegt ein Hardwaredefekt (Ethernetkabel, Netzwerkkomponenten) vor!

Die IPerf3-Messung “1 x Revers, Lokal/ Layer 2 direkt (Server => Client)” zeigt auf, dass die Netzwerkkarte des Clients mit Datenübertragungsraten > 778 MBit/s überfordert ist!

Mit dem nachfolgenden Befehl unter Linux Mint kontrollieren, welche Hardwarebeschleunigungen (Hardware-Offload) diese Netzwerkkarte unterstützt oder eben nicht unterstützt. Hier als Beispiel die Hardwarebeschleunigungen vom Intel I219LM:

# su
# ethtool –show-offload eth0
Features for eth0:
rx-checksumming: on
tx-checksumming: on
tx-checksum-ipv4: off [fixed]
tx-checksum-ip-generic: on
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp-mangleid-segmentation: off
tx-tcp6-segmentation: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-gre-csum-segmentation: off [fixed]
tx-ipxip4-segmentation: off [fixed]
tx-ipxip6-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-udp_tnl-csum-segmentation: off [fixed]
tx-gso-partial: off [fixed]
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off
rx-all: off
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: off [fixed]
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]
rx-gro-hw: off [fixed]

mokai

Hat sich erledigt. War wie gedacht das UPC vergessen hatte die Geschwindigkeit umzustellen. Ihr solltet da prüfen dass wenn wer nen gigarouter hat auch giga geliefert wird

millernet

So jetzt schwirrt mir langsam der Kopf vor lauter Messungen. Ich hab jetzt noch weitere gemacht:

Mein Setup:

Client (1 x Gigabit NIC, nicht die 10 GbE NIC!) - GS110EMX Hauptswitch - EdgeRouter - Server (2 x Gigabit NIC: WAN-Port EdgeRouter (192.168.50.0/24), LAN-Port EdgeRouter (192.168.1.0/24))

Hier die Messungen:

2 x Reverse, 1 Stream (Server => WAN EdgeRouter => Client)

ID] Interval Transfer Bandwidth Retr

[ 5] 0.00-300.00 sec 27.2 GBytes 777 Mbits/sec 1370 sender
[ 5] 0.00-300.00 sec 27.1 GBytes 777 Mbits/sec receiver

[ 5] 0.00-300.00 sec 27.1 GBytes 776 Mbits/sec 1202 sender
[ 5] 0.00-300.00 sec 27.1 GBytes 776 Mbits/sec receiver

1 x Reverse, 8 Streams (Server => WAN EdgeRouter => Client)

[ ID] Interval Transfer Bandwidth Retr
[ 5] 0.00-300.00 sec 3.46 GBytes 99.1 Mbits/sec 1099 sender
[ 5] 0.00-300.00 sec 3.46 GBytes 99.0 Mbits/sec receiver
[ 7] 0.00-300.00 sec 3.46 GBytes 99.1 Mbits/sec 1066 sender
[ 7] 0.00-300.00 sec 3.46 GBytes 99.0 Mbits/sec receiver
[ 9] 0.00-300.00 sec 3.46 GBytes 99.1 Mbits/sec 1110 sender
[ 9] 0.00-300.00 sec 3.46 GBytes 99.0 Mbits/sec receiver
[ 11] 0.00-300.00 sec 3.46 GBytes 99.1 Mbits/sec 1122 sender
[ 11] 0.00-300.00 sec 3.46 GBytes 99.0 Mbits/sec receiver
[ 13] 0.00-300.00 sec 3.46 GBytes 99.0 Mbits/sec 1133 sender
[ 13] 0.00-300.00 sec 3.46 GBytes 99.0 Mbits/sec receiver
[ 15] 0.00-300.00 sec 3.46 GBytes 99.1 Mbits/sec 1054 sender
[ 15] 0.00-300.00 sec 3.46 GBytes 99.0 Mbits/sec receiver
[ 17] 0.00-300.00 sec 3.46 GBytes 99.1 Mbits/sec 1060 sender
[ 17] 0.00-300.00 sec 3.46 GBytes 99.0 Mbits/sec receiver
[ 19] 0.00-300.00 sec 3.46 GBytes 99.1 Mbits/sec 1113 sender
[ 19] 0.00-300.00 sec 3.46 GBytes 99.0 Mbits/sec receiver
[SUM] 0.00-300.00 sec 27.7 GBytes 792 Mbits/sec 8757 sender
[SUM] 0.00-300.00 sec 27.7 GBytes 792 Mbits/sec receiver

1 x Revers, Lokal/ Layer 2 (Server => Netgear GS110EMX => EdgeRouter => Client)

[ ID] Interval Transfer Bandwidth Retr
[ 5] 0.00-300.00 sec 32.9 GBytes 941 Mbits/sec 1404 sender
[ 5] 0.00-300.00 sec 32.9 GBytes 941 Mbits/sec receiver

1 x Lokal/ Layer 2 (Client => EdgeRouter => Netgear GS110EMX => Server)

[ ID] Interval Transfer Bandwidth Retr
[ 5] 0.00-300.00 sec 32.9 GBytes 941 Mbits/sec 1625 sender
[ 5] 0.00-300.00 sec 32.9 GBytes 941 Mbits/sec receiver

2 x Lokal/ Layer 2 (Client => Netgear GS110EMX => Server)

[ ID] Interval Transfer Bandwidth Retr
[ 5] 0.00-300.00 sec 32.9 GBytes 942 Mbits/sec 120 sender
[ 5] 0.00-300.00 sec 32.9 GBytes 941 Mbits/sec receiver

[ 5] 0.00-300.00 sec 32.9 GBytes 942 Mbits/sec 0 sender
[ 5] 0.00-300.00 sec 32.9 GBytes 941 Mbits/sec receiver

2 x Revers, Lokal/ Layer 2 (Server => Netgear GS110EMX => Client)

[ ID] Interval Transfer Bandwidth Retr
[ 5] 0.00-300.00 sec 32.9 GBytes 941 Mbits/sec 537 sender
[ 5] 0.00-300.00 sec 32.9 GBytes 941 Mbits/sec receiver

[ 5] 0.00-300.00 sec 32.9 GBytes 941 Mbits/sec 536 sender
[ 5] 0.00-300.00 sec 32.9 GBytes 941 Mbits/sec receiver

1 x Revers, Lokal/ Layer 2 direkt (Server => Client)

[ ID] Interval Transfer Bandwidth Retr
[ 5] 0.00-300.00 sec 27.2 GBytes 778 Mbits/sec 0 sender
[ 5] 0.00-300.00 sec 27.2 GBytes 778 Mbits/sec receiver

1 x Lokal/ Layer 2 direkt (Client => Server)

[ ID] Interval Transfer Bandwidth Retr
[ 5] 0.00-300.00 sec 32.9 GBytes 942 Mbits/sec 0 sender
[ 5] 0.00-300.00 sec 32.9 GBytes 941 Mbits/sec receiver

1 x Lokal/ Layer 2 direkt (Client => EdgeRouter => Server)

[ ID] Interval Transfer Bandwidth Retr
[ 5] 0.00-300.00 sec 32.9 GBytes 942 Mbits/sec 0 sender
[ 5] 0.00-300.00 sec 32.9 GBytes 941 Mbits/sec receiver

1 x Lokal/ Layer 2 direkt, Reverse (Server => EdgeRouter => Client)

[ ID] Interval Transfer Bandwidth Retr
[ 5] 0.00-300.00 sec 32.9 GBytes 941 Mbits/sec 2177 sender
[ 5] 0.00-300.00 sec 32.9 GBytes 941 Mbits/sec receiver

Somit mein Fazit:

*	 Direkt verbunden läuft der Transfer zwischen Server => Client (Revers) langsamer als über die Switches ?!
*	 Sobald der EdgeRouter beteiligt ist, liegen hohe Retr-Raten vor. Auch wenn nur die Switching-Funktion des EdgeRouter genutzt wird.
*	 Revers weisst mein Hauptswitch (Netgear GS110EMX) höhere Paketverlustraten auf als normal.
*	 Wird die 10 Giga-NIC verwendet, dann ist mit hohen Retr zu rechnen (Client => Server), bei Reverse hingegen 0 (wie von @GrandDixence bereits erwähnt.) => Wurde in einer kurzen Verifizierungsmessung durchgeführt, welche oben nicht aufgelistet ist.
*	 ???!!!!!?

GrandDixence

Damit Datenübertragungsraten von 1 GBit/s mit einem Internetanschluss erzielt werden können, muss die Paketverlustrate < 0.001 % sein.

https://fasterdata.es.net/network-tuning/tcp-issues-explained/packet-loss/

https://www.switch.ch/network/tools/tcp_throughput/

Auch der Router/Firewall kann verlorene oder verfälschte Ethernet-Pakete verursachen!

GrandDixence

Verglichen mit Test 4 (iperf3test_4_local_300s.txt.pdf) betrug im Test 1 (iperf3test_1_300s.txt.pdf) die Paketverlustrate:

Verlorene Pakete aus Test 1 := Anzahl TCP-Retransmissions (Retr) = 7080 Ethernet-Pakete

Anzahl Ethernet-Pakete in Test 4 pro Sekunde := 941 MBit/s / 1500 Byte = 78417 Ethernet-Pakete pro Sekunde

Gemessene Paketverlustrate in Test 4:= 7080 / (300 s * 78417 Pakete/s) = 7080 / 23525100 = 0.000301 = 0.0301 %

Der Einfluss der Paketverlustrate in Abhängigkeit der Paketumlaufzeit (RTT) zeigt die Webseite:

https://fasterdata.es.net/network-tuning/tcp-issues-explained/packet-loss/

schön auf.

[https://de.wikipedia.org/wiki/Paketumlaufzeit](http:// https://de.wikipedia.org/wiki/Paketumlaufzeit)

Je weiter entfernt der Server, desto geringere Datenübertragungsraten können bei gleichbleibender Paketverlustrate erreicht werden.

GrandDixence

Jedenfalls ist mit Test 4 (iperf3test_4_local_300s.txt.pdf) nachgewiesen, dass das “Referenzsystem” in Ordnung ist. Die Messresultate von Test 4 sind sehr sauber. Ich empfehle das “Referenzsystem” noch in die andere Übertragungsrichtung mit dem Parameter “-R” zu prüfen:
[https://iperf.fr/iperf-doc.php](http:// https://iperf.fr/iperf-doc.php)

Weiter empfehle ich TCP-Messungen mit IPerf3 in beide Übertragungsrichtungen (1x ohne Parameter “-R”; 1x mit Parameter “-R”) in der Konstellation PC1<->Netgear-Switch<->PC2 um allfällige Mängel in den eingesetzten Ethernetkabel und im Netgear-Switch ausschliessen zu können.

Auf Grund der geringeren Anzahl von TCP-Retransmissions (Retr) aus den IPerf3-Messungen erscheint mir mein LANCOM 1781EF+ geeigneter für einen 1 GBit/s-Internetanschluss zu sein als der EdgeRouter 12.

Auf Grund der hohen Anzahl der TCP-Retransmissions (Retr) erscheint mir der EdgeRouter 12 in dieser Konfiguration für 1 GBit/s-Internetanschlüssen als ungeeignet. Die Konfiguration des EdgeRouter 12 ist gemäss Beitrag Nr. 99 zu optimieren, damit die Anzahl der TCP-Retransmissions auf 0 sinkt.

Wurden die beiden Mess-PC’s mit aktivem TCP SACK konfiguriert?

https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Selective_acknowledgments

millernet

Hier noch die restlichen Tests.

millernet

@GrandDixence Ich hab jetzt ein saubere Setup realisiert, welches aus zwei Linux Mint Clients besteht, welche direkt, über meinen Switch und über den EdgeRouter miteinander verbunden worden sind. Im Anhang wieder die Resultate. Der Retr ist sehr hoch, sobald der EdgeRouter WAN-LAN dazwischen hängt. Ich versuche jetzt den EdgeRouter mit reinem Routing zu testen, ohne Firewall und NAT.

Tests:

Test 1: 300 s, 1 stream, mit Switch & EdgeRouter dazwischen
Test 2: 300 s, 1 stream, mit Switch & EdgeRouter dazwischen
Test 3: 300 s, 8 streams, mit Switch & EdgeRouter dazwischen
Test 4: 300 s, 1 stream, lokal direkt verbunden/ Layer 2 ohne Switch oder EdgeRouter dazwischen
Test 5: 300 s, 1 stream, EdgeRouter dazwischen (Client direkt am EdgeRouter angeschlossen), ohne Switch
Test 6: 300 s, 1 stream, EdgeRouter dazwischen (Client direkt am EdgeRouter angeschlossen), ohne Switch, Hardware Offloading (https://help.ubnt.com/hc/en-us/articles/115006567467-EdgeRouter-Hardware-Offloading) auf dem EdgeRouter deaktiviert.
Test 7: 300 s, 1 stream, EdgeRouter dazwischen (Client direkt am EdgeRouter angeschlossen), ohne Switch, DPI disabled

millernet

Warum habe ich überhaupt nur mit Gigabit Internet angefangen…. mit 600 Mbit/s war das Leben noch so ruhig und beschaulich. Ich schaue mal, was ich heute noch messen kann.

GrandDixence

Mit IPerf3 werden sehr hardwarenahe Messungen durchgeführt. Bei Datenübertragungsraten im Gigabit-Bereich geht es um Zeitspiele im Mikrosekundenbereich (0.000001 Sekunde). Im Computerchip implementierte Hardwarebeschleunigungen (Hardware-Offloading), CPU-Auslastungen und SoC-Kühlung beeinflussen die Messresultate massgeblich.

https://en.wikipedia.org/wiki/TCP_offload_engine

https://en.wikipedia.org/wiki/System_on_a_chip

Bitte nicht vergessen, dass ein 1500 Byte grosses Ethernet-Datenpaket immer in < 12 µs (0.000012 Sekunde) von der Firewall/Router verarbeitet werden muss, damit konstante Datenübertragungsraten von 1 GBit/s überhaupt möglich sind.

Für aussagekräftige IPerf3-Messungen dürfen keine Emulatoren und virtuelle (Netzwerk-)komponenten eingesetzt werden. Deren Zeitspiele verfälschen die IPerf3-Messresultate massgeblich.

Für Windows-Betriebssysteme sind auf der IPerf3-Webseite ältere, auf Cygwin basierende IPerf3-Versionen erhältlich:

https://iperf.fr/

https://de.wikipedia.org/wiki/Cygwin

Diese älteren Versionen sollten für TCP-Messungen genügen. Für UDP-Messungen sollten diese älteren IPerf3-Versionen nicht eingesetzt werden!

Der 10GBit-Switch darf bei den IPerf3-Messungen nicht zum Nadelöhr werden. Sprich vom 10 GBit-Ethernetkabel kommen mehr Datenpakete daher als im weiterführenden 1 GBit-Ethernetkabel “Platz haben”. Dies würde zu Paketverlusten (Packet drop) beim 10GBit-Switch führen, was in den IPerf3-Messresultate als TCP-Retransmissions ersichtlich wäre (Retr > 0).

Am besten die IPerf3-Messungen mit einer durchgängigen 1 GBit-Ethernetkabel-Installation und mit zweien PC’s ohne Virtualisierung+Emulatoren durchführen. Für die IPerf3-Messungen muss das Heimnetzwerk unbelastet sein. Alle nicht für die Messungen benötigten Netzwerkkomponenten sind vorgängig abzuhängen.

Ubiquiti ist ein Hersteller von Billig-Netzwerkkomponenten. Diese Tests mit dem teuren Referenzequipment wird sehr wahrscheinlich aus Kostenspargründen bei Ubiquiti eingespart.

Programmierfehler und Konfigurationsfehler (siehe oben genannte EdgeRouter-Hardware-Offloading-Webseite) in der Firewall/Router können die Performance massgeblich beeinflussen.

https://www.lancom-forum.de/aktuelle-lancom-router-serie-f41/lancom-1781a-an-kabelmodem-cisco-ecp-3208-t13660-s15.html#p74261

Deshalb sind die oben genannten IPerf3-TCP-Messungen bei Internetanschlüssen im Gigabit-Ethernetbereich im Heimnetzwerk für jeden Privatanwender Pflicht.

millernet

@GrandDixence schrieb:

Danke für die IPerf3-Messresultate. Was nicht gut ist:

1.) Die Fehlermeldung “iperf3: getsockopt - Protocol not available” muss weg, IPerf3 fehlt der Zugriff auf irgendwelche vom Betriebssystem bereitgestellten Konfiguriationsoptionen des TCP/IP-Netzwerkstacks.

Da im “console output” die IPerf3-Befehlszeile fehlt, kann nicht nachvollzogen werden, woran dies liegen könnte. Wenn ein oder mehrere Windows-Betriebssysteme für die IPerf3-Messungen eingesetzt wurden, empfehle ich das Wiederholen der IPerf3-Messungen ab einer Linux Live-CD. Einfach das ISO-Image einer Linux Live-CD herunterladen und auf zwei USB-Memorysticks installieren.

https://de.opensuse.org/SDB:Live_USB_Stick

Danach die beiden Rechner ab dem USB-Memorystick starten.Eventuell muss nach dem Linux-Start IPerf3 oder ein ähnliches Netzwerkmesstool installiert werden, da nicht im Lieferumfang der Live-CD enthalten.

Mit dem Einsatz einer Linux Live-CD können auch eventuelle negative Einflüsse der Antivirussoftware (und weiterem “Windows-Schrott”) ausgeschlossen werden.

2.) In der ersten Sekunde nach dem Messstart werden 1296506928 TCP-Retransmissions festgestellt, danach stellt IPerf3 keine einzige TCP-Retransmission mehr fest. Da stimmt etwas nicht. Dieses Fehlverhalten könnte durch die Fehlermeldung in Punkt 1) verursacht sein.

3.) Die häufigen Zusammenbrüche der Datenübertragungsraten (< 700 MBit/s) bei den 1 Stream TCP-Messungen sind gar nicht gut. Bei den Zusammenbrüchen der Datenübertragungsraten sind wahrscheinlich TCP-Retransmissions vorgefallen, diese wurden aber wegen dem unter Punkt 2) beschriebenen Fehlverhalten nicht von IPerf3 aufgezeichnet.

4.) Bei den 1 Stream TCP-Messungen “Layer 2 switching” sind Zusammenbrüche der Datenübertragungsrate < 900 MBit/s ersichtlich. Bei 1 Stream TCP-Messungen darf die Datenübertragungsrate nur in den ersten 2 Sekunden nach dem Messstart (Stichwort: TCP Slow Start) unter 900 MBit/s fallen. => iperf3test_2_local, 13 bis 14 Sekunden und 73.00-74.00 nach Messstart sind ja grauenhaft!

Wurde hier ein schlechter Switch eingesetzt? Ich empfehle die Wiederholung der 1 Stream TCP-Messungen “Layer 2 switching” mit zwei direkt per Gigabit-Ethernetkabel verbundenen PC’s. Ein Crossover-Kabel ist bei Gigabit-Ethernet nicht erforderlich. Befinden sich hochwertige Netzwerkkarten in den beiden Mess-PC’s? Alle Antivirus-Software und weiteren “Windows-Schrott” von den Windows-Rechnern deinstalliert?

Weitere mögliche Ursache für die Zusammenbrüche der Datenübertragungsraten könnte “Ethernet Flow Control” sein. Hier empfiehlt sich die Kontrolle der Ethernet-Statistikseiten der beteiligten Netzwerkkomponenten.

[https://en.wikipedia.org/wiki/Ethernet\_flow\_control](http:// https://en.wikipedia.org/wiki/Ethernet_flow_control)

Danke für deine Analyse. Der Fehler in 1 lässt sich erklären, da ich als Client Subsystem for Linux (Ubuntu aus dem Store) unter Windows 10 verwendet habe. Offenbar greift da iPerf3 auf eine Kernelfunktion zurück, welche seitens Subsystem nicht vorhanden ist.

Das Setup müsste entschlackt werden, nur kann ich auf die schnelle keine zwei Hardware Linux Clients bereitstellen und meine Frau würde parallel halt auch noch gerne ins Internet……:

Client: Windows 10 mit Subsystem for Linux (Ubuntu): iperf3 -c 192.168.1.101 -t 300 –logfile iperf3test_2_local.txt

*	 über 10 Gigabit Copper an Switch angebunden.

Server: Ubuntu Server 18.04 LTS auf einem Proxmox/ KVM Hypervisor. Netzwerkkarte wurde über eine OVS-Bridge eingebunden. Hier haben wi rhalt wieder zwei virtuelle Schichten dazwischen (virtueller Switch und virtuelle Netzwerkkarte).
Verwendeter Switch: Netgear GS110EMX

Aktuell mache ich mit CNLAB gerade eine Messreihe, wo die Connect-Box im Router Modus ist und ich den Rechner direkt per LAN angeschlossen habe. Da kann ich die gleichen Einbrüche detektieren, welche ich bereits beim EdgeRouter bemerkt habe. Für all diese Tests gibt es teures Referenzequipment und Standartisierungen, welche Ubiquiti mit grosser Wahrscheinlichkeit regelmässig mit ihrem Equipment durchführt. Ich versuche heute Abend mal ein neues Referenzsetup aufzubauen mit weniger Layers dazwischen.

GrandDixence

Danke für die IPerf3-Messresultate. Was nicht gut ist:

1.) Die Fehlermeldung “iperf3: getsockopt - Protocol not available” muss weg, IPerf3 fehlt der Zugriff auf irgendwelche vom Betriebssystem bereitgestellten Konfiguriationsoptionen des TCP/IP-Netzwerkstacks.

Da im “console output” die IPerf3-Befehlszeile fehlt, kann nicht nachvollzogen werden, woran dies liegen könnte. Wenn ein oder mehrere Windows-Betriebssysteme für die IPerf3-Messungen eingesetzt wurden, empfehle ich das Wiederholen der IPerf3-Messungen ab einer Linux Live-CD. Einfach das ISO-Image einer Linux Live-CD herunterladen und auf zwei USB-Memorysticks installieren.

https://de.opensuse.org/SDB:Live_USB_Stick

Danach die beiden Rechner ab dem USB-Memorystick starten.Eventuell muss nach dem Linux-Start IPerf3 oder ein ähnliches Netzwerkmesstool installiert werden, da nicht im Lieferumfang der Live-CD enthalten.

Mit dem Einsatz einer Linux Live-CD können auch eventuelle negative Einflüsse der Antivirussoftware (und weiterem “Windows-Schrott”) ausgeschlossen werden.

2.) In der ersten Sekunde nach dem Messstart werden 1296506928 TCP-Retransmissions festgestellt, danach stellt IPerf3 keine einzige TCP-Retransmission mehr fest. Da stimmt etwas nicht. Dieses Fehlverhalten könnte durch die Fehlermeldung in Punkt 1) verursacht sein.

3.) Die häufigen Zusammenbrüche der Datenübertragungsraten (< 700 MBit/s) bei den 1 Stream TCP-Messungen sind gar nicht gut. Bei den Zusammenbrüchen der Datenübertragungsraten sind wahrscheinlich TCP-Retransmissions vorgefallen, diese wurden aber wegen dem unter Punkt 2) beschriebenen Fehlverhalten nicht von IPerf3 aufgezeichnet.

4.) Bei den 1 Stream TCP-Messungen “Layer 2 switching” sind Zusammenbrüche der Datenübertragungsrate < 900 MBit/s ersichtlich. Bei 1 Stream TCP-Messungen darf die Datenübertragungsrate nur in den ersten 2 Sekunden nach dem Messstart (Stichwort: TCP Slow Start) unter 900 MBit/s fallen. => iperf3test_2_local, 13 bis 14 Sekunden und 73.00-74.00 nach Messstart sind ja grauenhaft!

Wurde hier ein schlechter Switch eingesetzt? Ich empfehle die Wiederholung der 1 Stream TCP-Messungen “Layer 2 switching” mit zwei direkt per Gigabit-Ethernetkabel verbundenen PC’s. Ein Crossover-Kabel ist bei Gigabit-Ethernet nicht erforderlich. Befinden sich hochwertige Netzwerkkarten in den beiden Mess-PC’s? Alle Antivirus-Software und weiteren “Windows-Schrott” von den Windows-Rechnern deinstalliert?

Weitere mögliche Ursache für die Zusammenbrüche der Datenübertragungsraten könnte “Ethernet Flow Control” sein. Hier empfiehlt sich die Kontrolle der Ethernet-Statistikseiten der beteiligten Netzwerkkomponenten.

[https://en.wikipedia.org/wiki/Ethernet\_flow\_control](http:// https://en.wikipedia.org/wiki/Ethernet_flow_control)

millernet

Hier noch der letzte Test.

« Vorherige Seite Nächste Seite »