Gemäss den im Beitrag Nr. 6 abgebildeten Web100-Parameter wurden keine TCP-Retransmissions (Übertragungswiederholungen) wegen fehlenden oder fehlerhaft übertragenen TCP-Datenpakete durchgeführt. Auch die Anzahl der doppelt bestätigten Datenpaketlieferungen (DupAck) ist sehr gering. Somit ist die Netzwerkverbindung störungsfrei.
Wie Daniele in Beitrag Nr. 6 korrekt erkannt hat, wird die TCP-Verbindund durch das “TCP Receive Window” Client-seitig begrenzt (=> siehe Web100-Parameter: SndLimTimeRwin).
Füllt man im “TCP Throughput Calculator” von Switch:
https://www.switch.ch/network/tools/tcp_throughput/
unter “Calculate Bandwidth-delay Product and TCP buffer size” die von diesem Internetanschluss bekannten Werte:
- RTT: 10 ms (ms: Millisekunden => zu erwartende Paketumlaufzeit)
- WIN: Upstream: 64 KByte (gemäss MaxRwinRcvd)
Downstream: 256 KByte (gemäss y-Achse des Diagramms => CurRwinRcvd)
ein, werden ziemlich genau die gemessenen Werte vom “Bandwidth-delay Product”-Rechner (BDP) ausgespukt:
https://de.wikipedia.org/wiki/Verz%C3%B6gerungs-Bandbreiten-Produkt
- maximum throughput (maximal mögliche Datenübertragungsrate):
Upstream: 52 MBit/s
Downstream: 209 MBit/s
Verletzung “Gute Performance”-Regel Nr. 14 + 15:
https://community.sunrise.ch/t5/Internet-mit-Modem/Diagnose-Tool-der-Connect-Box-sagt-quot-Ihr-Heim/m-p/100045/highlight/true#M4573
Damit Datenübertragungsraten um 940 MBit/s erreicht werden können, muss das TCP Receive Window (RwinRcvd) gemäss dem oben genannten Rechner mindestens:
1140 KByte
gross sein (@ 10 ms RTT). Bei weit entfernt stehenden Servern muss das TCP Receive Windows noch deutlich grösser sein! Im Extremfall wird von modernen Windows-Betriebssystemen ein TCP Receive Window von 16 MegaByte eingesetzt!
Ab Windows Vista unterstützen Windows-Betriebssysteme die vollautomatische Vergrösserung und Verkleinerung des TCP Receive Window bis maximal 16 MB:
https://docs.microsoft.com/en-us/windows-server/networking/technologies/network-subsystem/net-sub-performance-tuning-nics#bkmk_tcp
wenn “TCP receive window autotuning” korrekt konfiguriert wurde:
# netsh interface tcp show global
=> Receive Window Auto-Tuning Level : normal
\=> Autom. Abstimmungsgrad Empfangsfenster: normal
Auch unter Linux ist ein entsprechendes Tuning der vollautomatischen Vergrösserung und Verkleinerung des TCP Receive Window empfehlenswert. Standardmässig ist das maximal mögliche TCP Receive Window bei Linux-Rechnern zu klein dimensioniert!
# more /etc/sysctl.conf
TCP Window vergrössern auf
16 MegaByte TCP-Window Size (analog zu Windows Vista/7)
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 16384 33554432
Für Linux siehe auch:
https://www.kernel.org/doc/html/latest/networking/ip-sysctl.html
“Allgemeine Fehlersuche und Fehlereingrenzung” gemäss Beitrag Nr. 3 durchführen:
https://community.sunrise.ch/t5/Connect-Box/Gigaconnect-Aussetzer/m-p/152213#M3445
\=> Welche Software wurde auf diesem Rechner seit Anfang Oktober 2020 installiert?
\=> Wurden auf diesem Rechner so “Schrottsoftware aus dem Windows XP-Zeitalter” à la “UPC Fiber Power Optimizer” mit Administratorrechten ausgeführt, welche das TCP Receive Window negativ beeinflussen?
https://www.cablemodem.ch/cableforum/viewtopic.php?f=2&t=8784
\=> Grösse des “TCP Receive Window” mit Wireshark feststellen.
https://community.sunrise.ch/d/14885-tiefe-bandbreite-bei-ssl-vpn-trotz-higspeed-anschluss/15