@wollmich
Auch bei ungestörten Internetanschlüssen mit EuroDOCSIS 3.0 sehe ich im Broadband Quality Monitor (BQM) im Tagesverlauf einige kurze Paketumlaufzeitenspitzen > 80 Millisekunden (RTT).
https://de.wikipedia.org/wiki/Paketumlaufzeit
Diese kurzzeitigen längeren gelben Spitzen werden vermutlich durch die "Media Acquisition” verursacht. Der Internetanschluss über das Fernsehkabelnetzwerk (EuroDOCSIS) ist bekanntlich ein mit Zeitschlitzen arbeitendes “Shared Medium”. Siehe dazu:
https://community.sunrise.ch/d/8427-wird-upc-jemals-konkurrenzfahig-mit-glaseranbieter/18
https://community.swisscom.ch/t5/Internet-allgemein/XGS-PON-Glasfaser-Wie-funktioniert-die-Rationierung/m-p/772303#M68963
Ist das Fernsehkabelnetzwerk (konkreter: die Zelle) überlastet, können die gelben Spitzen im BQM “durch die Decke schlagen”. Siehe auch:
https://www.golem.de/news/auslastung-wenn-es-abend-wird-im-kabelnetz-1709-130142.html
Im schlimmsten Fall resultiert ein Datenpaketverlust. Was sich als rote Kurve im BQM ersichtlich macht. Siehe bei der oberen Abbildung die höchste gelbe Spitze um “8pm”. Dort ist kurz die rote Kurve ersichtlich.
Tipp: Vom Vortag sind die Messresultate des BQM als XML-Datei erhältlich. Diese XML-Datei sollte für genauere Untersuchungen beigezogen werden!
Die hier von wollmich abgebildeten, längeren gelben Spitzen könnten durch “Bufferbloat” verursacht sein. Wenn die längeren gelben Spitzen nachts fehlen, ist das ein klarer Indiz für Bufferbloat.
https://de.wikipedia.org/wiki/Bufferbloat
Gegen Bufferbloat hilft der Einsatz eines Traffic Shaper". Siehe dazu:
https://community.sunrise.ch/d/27578-erfahrungswerte-cnlab-ux-bufferbloat-test
https://community.sunrise.ch/d/8427-wird-upc-jemals-konkurrenzfahig-mit-glaseranbieter/32
https://community.swisscom.ch/t5/Internet-allgemein/Netflix-streaming-verursacht-hohen-Ping-90ms/m-p/778394#M69411
https://community.swisscom.ch/t5/Internet-allgemein/Apple-Dienste-funktionieren-nicht-mit-Internetbox-3/m-p/775585#M69205
Weshalb die Paketumlaufzeiten so wichtig für die Performance eines Internetanschlusses sind, wurde unter:
https://mobilecommunity.ch/wbb/index.php?thread/326-salt-fiber-oder-salt-unlimited-surf-f%C3%BCr-heimnetzwerk/&postID=2526#post2526
aufgezeigt. Man beachte das “Fritz! Talk 14”-Video.
(Euro-)DOCSIS 3.1 bringt Besserungen im Bereich der Paketumlaufzeiten (“Low Latency”). Jedoch sind diese Vorteile wahrscheinlich erst durch den Internetanschlussanbieter (ISP: hier UPC-Sunrise) nutzbar, wenn sowohl der Downstream (Download-Richtung), wie auch der Upstream (Upload-Richtung), mit einem DOCSIS 3.1-Kanal realisiert ist. Das ist heute im Fernsehkabelnetzwerk von UPC-Sunrise (noch) NICHT der Fall! Siehe dazu:
https://community.sunrise.ch/d/32188-upload-nur-100mbps/8
Beim Einsatz eines Traffic Shaper ist zu beachten, dass der Traffic Shaper bei der rechnerinternen Verarbeitung der ankommenden Datenpakete durch die Verarbeitungszeit die Paketumlaufzeit mehr oder weniger verlängert. Diese Verarbeitungszeit wird von CAKE als “pk_delay” (packet delay) im Kommandozeilenbefehl # tc -s qdisc show ausgewiesen. Siehe dazu die Abbildung unter:
https://community.swisscom.ch/t5/Internet-allgemein/Netflix-streaming-verursacht-hohen-Ping-90ms/m-p/778394#M69411
Ein Traffic Shaper wie CAKE benötigt Rechenzeit um alle ankommenden Datenpakete einem Datenstrom zuordnen zu können (flow isolation). Diese Zuordnung ist erforderlich, damit die Datenpakete vom Traffic Shaper korrekt priorisiert werden können.
Beim Einsatz vom CAKE auf Raspberry Pi 4 (Ubuntu 20.04 LTS) stelle ich fest, dass bei grösserem Datenaufkommen die durchschnittliche Paketumlaufzeit um rund 7 Millisekunden in die Höhe schnellt (blaue Kurve). In der Abbildung lief im Zeitraum von “12pm” bis “2pm” der Fernseher. Der kontinuierliche Datenstrom vom IPTV, von rund 10 MBit/s, erhöhte die maximale Paketumlaufzeit (gelbe Kurve) um rund 25 Millisekunden.
Beim Einsatz von WLAN ist der “WLAN Background Scan” zu beachten. Siehe dazu:
https://community.sunrise.ch/d/31839-schlechtes-internet-durch-paketverlust
