Disconnect EA FIFA21 / Hohe Pings

roterblauwal · 2021-05-14T16:41:21+00:00

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

GrandDixence

@millernet
Beim Einsatz vom “Broadband Quality Monitor” von https://www.thinkbroadband.com/ muss der Betrachter sich bewusst sein, dass dieser 24h/7 Tage-Leitungstest eine hohe zeitliche Auflösung von einer Sekunde aufweist. Im Intervall von einer Sekunde (1000 ms) wird ein Ping versendet und muss von der zu prüfenden Gegenstelle mit einem Pong beantwortet werden.
https://www.thinkbroadband.com/faq/broadband-quality-monitor

Hingegen ist die zeitliche Auflösung des abgebildeten “Smoke Ping” sehr gering. Nämlich 5 Minuten (300 s). Im Intervall von 5 Minuten werden 20 Pings versendet. Die 20 Pings werden zeitlich direkt nacheinander versendet.

Der von millernet abgebildete “Broadband Quality Monitor” eines G.Fast-Kabelmodems zeigt schön auf, weshalb ich kein Fan von Internetanschlüssen über das Telefonkabel (G.Fast, VDSL, ADSL) bin:

Um 22:00 Uhr MESZ (8 pm) wurde vom Elektrizitätswerk per Rundsteuersignal der billigere Nachtstromtarif freigegeben.
https://de.wikipedia.org/wiki/Rundsteuertechnik

Dies führte dazu, dass ein am Telefonkabel nahe liegender elektrischer Verbraucher (zum Beispiel: Warmwasserboiler) eingeschaltet wurde. Dieser elektrische Verbraucher stört die hochfrequente Signalübertragung im Telefonkabel massiv. Dies führt zu Paketverlusten und erhöhten Paketumlaufzeiten. Bis um 08:00 Uhr MESZ (6 am) das Elektrizitätswerk diesen störenden elektrischen Verbraucher ausschaltete.

Eine noch höhere zeitliche Auflösung bieten adaptive Ping-Messungen. An diesem G.Fast-Internetanschluss sollte zu nächtlicher Stunde adaptive Ping-Messungen durchgeführt werden. Diese Ping-Messungen werden die Messresultate vom “Broadband Quality Monitor” bestätigen.
https://community.sunrise.ch/d/8569-gigaconnect-aussetzer/25

Wie durch den Swisscom-Mitarbeiter Patrick S. unter:
https://community.swisscom.ch/t5/Internet-Allgemein/U72-Kabel-Signal-Rausch-Abstand-und-Geschwindigkeit/m-p/666374#M62566
bereits bestätigt wurde, sind Internetanschlüsse über Telefonkabel (G.Fast, VDSL, ADSL) sehr anfällig gegen elektrische Störsignale von aussen, wie zum Beispiel:

PowerLAN/PowerLine/PLC -> https://de.wikipedia.org/wiki/PowerLAN
Amateurfunk -> https://de.wikipedia.org/wiki/Amateurfunkdienst
Schaltnetzteile von Ständerlampen und so weiter. -> https://de.wikipedia.org/wiki/Schaltnetzteil

Jede neuere Anschlusstechnik für den Internetanschluss über das Telefonkabel wird noch höhere Frequenzen für die Signalübertragung verwenden. Damit wird der Internetanschluss über das Telefonkabel noch anfälliger für Störsignale von aussen. Ja, der Internetanschluss über das Telefonkabel wird sogar selber zum Störsignalsender und stört andere elektrische Systeme. Siehe dazu “Gute Performance”-Regel Nr. 19:
https://community.sunrise.ch/d/4397-diagnose-tool-der-connect-box-sagt-ihr-heim-netzwerk-hat-derzeit-einige-probl/27

Beim Einsatz eines Internetanschlusses über das Telefonkabel sollten im Kabelmodem folgende Werte geprüft werden:

Zeitpunkt der letzten Synchronisation mit dem Gesprächsparter des Kabelmodems (DSLAM).
Zähler der fehlerbehafteten, unkorrigierten Datenpakete nach der Vorwärtsfehlerkorrektur (FEC)
Aktiver Einsatz von Vectoring.

Das Kabelmodem sollte möglichst lange ohne Synchronisationsverlust arbeiten. Somit sollte die letzte Synchronisation möglichst weit in der Vergangenheit liegen.

Der “Zähler der fehlerbehafteten, unkorrigierten Datenpakete nach der Vorwärtsfehlerkorrektur (FEC)” heisst bei G.Fast/VDSL/ADSL: CRC

https://community.sunrise.ch/d/14846-starke-upload-schwankungen-mit-giga-box/18

Der CRC-Zähler sollte auf dem Wert “0” stehen bleiben. Siehe hier für ein anschauliches Beispiel:
https://community.swisscom.ch/t5/Internet-Allgemein/U72-Kabel-Signal-Rausch-Abstand-und-Geschwindigkeit/m-p/666357#M62565

Der Internetanschluss über das Telefonkabel sollte Vectoring einsetzen. Siehe dazu:
https://community.swisscom.ch/t5/Internet-Allgemein/langsames-Internet-und-kaum-Mobile-Signal/m-p/668537#M62677

millernet

GrandDixence Es ist mir schon bewusst, dass Smokeping in wesentlich grösseren Intervallen “pingt”. Es ging um den Vergleich, insbesondere in Bezug auf den “smoke”,(https://oss.oetiker.ch/smokeping/doc/reading.en.html) zwischen einem Sunrise-UPC DOCSIS 3.↉.1 Internetanschluss und einem FTTS G.fast Anschluss von Wingo/Swisscom:

The detail graph provides a large amount of information for a single target as seen from a single server. The line color depicts the amount of lost packets and the dark area around the line shows the amount of variation between individual probes.
Hier sieht man sehr schön den Switchover von G.fast auf DOCSIS 3.↉.1:

Die Varianz (“smoke”) zeigt deutliche Unterschiede und die Latenzzeit ist 40% grösser.

Die vermeintlichen Muster mit den Rundsteuersignalen sind auch verschwunden. In meinem Haus gibt es eine Wärmepumpe mit Boiler. Dieser Boiler hat ein zusätzliches Heizelement mit Legionellenschaltung. Wann diese Legionellenschaltung genau anspringt, müsste ich in Erfahrung bringen. Das verbleibende Muster stammt vermutlich vom Modem, wie bei thinkbroadband erläutert. Ich könnte noch die Wingo Internet Box (Internet Box 2 der Swisscom mit Wingo Kleber auf dem Swisscom Logo…) noch mit dem Draytek Vigor 166 vergleichen.

Auch die diversen Nachteilen sind mir als langjähriges Mitglied im Swisscom Forum bekannt:

Marode Kupferleitungen.
Eindringen von Wasser in Kabelstränge und Verteiler
Bridge Taps
Lose Klemmen oder schlechte Verbindungen an Unterverteilern.
CB-Funk: https://community.swisscom.ch/t5/Router-Hardware/CRC-Fehler-wegen-HF-Einstrahlung/m-p/668819#M34947 oder auch https://community.swisscom.ch/t5/Internet-Allgemein/U72-Kabel-Signal-Rausch-Abstand-und-Geschwindigkeit/m-p/666323
Freileitungen und Gewitter
Powerline
Crosstalk (wird über Vectoring versucht auszugleichen, gelingt aber nicht immer)

Bei Kabelnetzen habe ich aber auch diverse externe Einflüsse, wovon Ingress Störungen von losen oder defekten Steckverbindungen, defekten Verteilern, Verstärkern oder
Endkundengeräte die schlimmsten sind.

Nino_52

hi @GrandDixence,
Deine Beschreibung in dieser Sache ist leider nicht Sachgerecht:

Dies führte dazu, dass ein am Telefonkabel nahe liegender elektrischer Verbraucher (zum Beispiel: Warmwasserboiler) eingeschaltet wurde. Dieser elektrische Verbraucher stört die hochfrequente Signalübertragung im Telefonkabel massiv. Dies führt zu Paketverlusten und erhöhten Paketumlaufzeiten. Bis um 08:00 Uhr MESZ (6 am) das Elektrizitätswerk diesen störenden elektrischen Verbraucher ausschaltete.

Es ist ja so, dass z.B. 8h-Boiler via einem Rundsteresignal, welches auf das Netz aufmoduliert sind, gesteuert werden.

150…1500Hz; die neueren Anlagen sind <500Hz, gehalten)
für jene, welche wissen möchten welche Frequenz an seinem Wohnort gilt:

http://rundsteuerung.de/frequenzen/schweiz.html

Ein Boiler wird wie via Rundsteuersignal freigegeben.
Eingeschltet wird er nur, wenn ein Heizbedarf; mittels Thermostat dedektiert; besteht. Ist die Temperatur zu niedrig wird ab Freigabe eingeschaltet und bei >Solltemperatur abgeschaltet. Ein 8h/6h/4h-Boiler, je nach dem welcher eingebaut ist, benötigt für ein Aufheizen von Kaltwasser auf Solltemperatur maximal eben jene 4/6/8 Stunden, nur ist in den seltensten Fällen der Boiler vollständig abgekaltet, Daher geschiet die Abschaltung bedeutend früher, als das Sperrsignal durch das Netz erfolgt. Dazu kommt, dass ein Boiler eine Ohmsche Last ist, im Gengensatz zu Induktiven oder Kapazitiveb Verbraucher, was bedeutet, dass keine Frequenzbeinflussende Störungen auftreten.

Dazu muss auch erwähnt werden, dass Rundsteuersignale, je nach Versorger, auch sehr oft während des ganzen Tagesablauf erfolgen; insbesondere dann, wenn eine Grenzlaststeuerung in Anwendung ist.
Sind diese Rundsteuersignal ein Problem, dann müsste sich das dadurch manifestieren, dass immer dann, wenn ein solches Signal aufmoduliert wird Störungen auftreten. Diese müssten dann aber in der Regel für ca. 5..10s rythmisch auftreten; ist die durchschnittliche Zeittauer einer Sendung. Nach der Tarifumschaltung erfolgen jedoch viele Sendungen für die diversen Gruppen (bei den TBGN z.B. sind >70 Gruppen in Betrieb) und daher müssten zu jenem Zeitpunkten die Störungen gestaffelt erkennbar sein.

Ich glaube kaum, dass diese für diese Störungen, in den Protoklierten Ansichten, die Ursache sind.

Gruss Nino

GrandDixence

Naja, das Fernsehkabel ist ein “Shared Medium”. Das Telefonkabel ist kein Shared Medium. Bedingt durch “Shared Medium” verliert man beim Einsatz von EuroDOCSIS einige Millisekunden Latenz-/Paketumlaufzeit gegenüber G.fast.

https://mobilecommunity.ch/wbb/index.php?thread/326-salt-fiber-oder-salt-unlimited-surf-f%C3%BCr-heimnetzwerk/&postID=2526#post2526

G.fast ist de facto eine Full Duplex-fähige Internetanschlusstechnik (-> TDD). Somit können beide Teilnehmer (Kabelmodem und DSLAM) jederzeit, wann sie wollen, praktisch unverzögert Datenpakete senden (-> tiefe Zugriffszeiten).
https://www.itu.int/en/ITU-T/studygroups/com15/Documents/Overview%20of%20SG15%20Q4%20xDSL%20and%20G.(mg)fast.pdf

https://de.wikipedia.org/wiki/Duplex_(Nachrichtentechnik)

https://en.wikipedia.org/wiki/Time-division_multiplexing

Bei einem Shared Medium dürfen Datenpakete nur versendet werden, wenn ein freier und verfügbarer Zeitschlitz (Slot) vorhanden ist. Somit verzögert sich der Versand der Datenpakete praktisch immer. Daraus resultieren längere Zugriffszeiten und deren Variationen. Diese Variationen sind in den Smoke Pings als “grauer Rauch” ersichtlich. Je stärker das Netzwerk ausgelastet ist, desto seltener findet ein Netzwerkteilnehmer einen freien und verfügbaren Zeitschlitz (Slot) für den Datenversand. Dadurch schnellt die Zugriffszeit in die Höhe.
https://community.swisscom.ch/t5/Mobile/Sendemasten-Zellen-Auslastung-als-OpenData/m-p/645308#M8363

Wie im Beispiel des Mobilfunk gut ersichtlich ist, verbessert die Forschung und Weiterentwicklung der Internetanschlusstechniken die Latenz- und Paketumlaufzeiten fortlaufend. Man beachte dazu die Angabe “Pingzeiten” in der Grafik unter:
https://www.5g-anbieter.info/speed/5g-ping.html

Ob die Paketumlaufzeit nun 12 Millisekunden oder 7 Millisekunden beträgt, kann Otto-Normalbenutzern und den Gamern ziemlich egal sein. Da kaum ein spürbarer Unterschied in den Anwendungen feststellbar. Interessant und spürbar ist jeglicher Paketverlust (rote Linie) und die hohen, gelben Spitzen der Paketumlaufzeit > 100 ms.

Wohin die Reise bei EuroDOCSIS bezüglich Latenz- und Paketumlaufzeit in den nächsten Jahren geht, kann man im “Low Latency DOCSIS”-Whitepaper nachlesen:
https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=0affb960-25f4-44f9-b747-74ad8555fd06&__hstc=217413636.c7da90edb3c9e298e0b05baeb3317518.1557509545678.1557786603001.1557789533082.8&__hssc=217413636.104.1557789533082&__hsfp=3956899065

millernet

GrandDixence Danke für deine Ausführungen und die interessante Folie für meine “Bibliothek”. In der Tat, G.fast erlaubt dank TDD sehr flexible Profile. Theoretisch wären auch 250 / 250 Mbit/s möglich, was von der Swisscom aber nicht angeboten wird. G.fast wurde von Anfang an als die letzten Meter zwischen Glasfaser und Modem entwickelt und ist Prinzip bedingt dediziert, zumindest bis zum CAN resp. Micro-CAN. Und wie in der Folie auch erwähnt wird, kann G.fast auch über bestehende COAX-Hausinstallationen verwendet werden.

Die regelmässigen gelben Spikes / Ausschläge kann ich mit internen Pings von meinem Netzwerk auf tick.switch.ch (Periode: 1000 ms = 1 s) nicht ganz reproduzieren. Selbst wenn da etwas Regelmässiges vorhanden wäre, dann sind die Ausschläge immer noch geringer als die mittlere Latenzzeit mit dem shared medium DOCSIS 3.0 / 3.1 (ab 21.25 erfolgte die Umschaltung von G.fast auf DOCSIS) :

Du hast nur teilweise Recht: Wenn ich eine über 5 ms geringere Latenzzeit habe, ergibt dies schon gewisse Vorteile für Gamer. Die Unterschiede sind frappant. Da muss DOCSIS 3.1 sich verbessern resp. mit korrekter Implementierung von AQM und Low Latency DOCSIS (LLD) endlich aufholen. Das erklärte Ziel von LLD ist ja < 5 ms im 99 Perzentil.

https://www.cablelabs.com/technologies/low-latency-docsis

GrandDixence

Zum Vergleich: Adaptive Ping-Messung auf tick.switch.ch (IPv4) mit einer QoS-Priorisierung (-> Gute Performance-Regel Nr. 22) und einem EuroDOCSIS 3.0-Kabelmodem (Ubee EVM3236) im Bridge-Modus an einem Internetanschluss von UPC-Sunrise:
--- tick.switch.ch ping statistics --- 172605 packets transmitted, 172599 received, 0% packet loss, time 1969515ms rtt min/avg/max/mdev = 6.265/11.241/32.323/1.176 ms, pipe 3, ipg/ewma 11.410/11.269 ms

Man beachte den gemessenen Wert “mdev” -> mean deviation
https://www.mathsisfun.com/data/mean-deviation.html

@millernet
Mich würde noch interessieren, was die Ursache für die Ausschläge > 13 ms bei den Paketumlaufzeitenmessungen mit dem G.fast-Internetanschluss sein könnte.

Gemäss dem Dokument “E_CPE_Requirements_Library_WAN_xDSL_G.fast&Fibre” erhältlich auf der Swisscom-Webseite unter “Hilfsdokumente”:
https://www.swisscom.ch/de/business/wholesale/angebot/anschluesse/BBCS.html
müssen alle von der Swisscom zugelassenen G.fast-Kabelmodeme “physical retransmission” unterstützen. Diese Angabe “physical retransmission” interpretiere ich als G.998.4.
https://www.itu.int/rec/T-REC-G.998.4/en

Gemäss der Webseite:
https://draytek.co.uk/support/guides/kb-what-is-vdsl-vectoring-sra-and-ginp

G998.4 operates at the physical layer. The transmitting modem keeps a copy of transmitted data in a retransmission buffer. If the receiver detects corruption (by way of a checksum) a retransmission is requested. If the transmitter responds in time, the data is repaired. The round-tip time of a retransmission should be <4ms. If the transmitter doesn’t retransmit in time, the corrupt data is forwarded for higher level protocols to sort out.

dürfte eine Paketumlaufzeitspitze wegen “physical retransmission” bei G.fast nicht höher als rund 11 ms sein (7 + 4 ms). Und andere mögliche Gründe als die “physical retransmission” für deutlich längere Paketumlaufzeiten bei einem unbelasteten G.fast-Internetanschluss sind mir nicht bekannt.

Zudem wird das eingesetzte Kabelmodem Draytek Vigor 166 nicht in der Liste der von Swisscom zugelassenen G.fast-Kabelmodeme geführt?! -> Dokument “E_BBCS_Supporting-Document_Proved-Equipment” unter Hilfsdokumente auf der bereits genannten Swisscom-Webseite

millernet

GrandDixence Mich würde noch interessieren, was die Ursache für die Ausschläge > 13 ms bei den Paketumlaufzeitenmessungen mit dem G.fast-Internetanschluss sein könnte.

Das wüsste ich auch gerne. Tatsächlich ist der Draytek Vigor 166 nicht auf der Liste, was ich vor dem Kauf nicht gewusst habe. Das Gerät ist preislich attraktiv, sehr kompakt, hat einen sehr guten Funktionsumfang und einen Bridge- resp. Modem-Modus. Eine Alternative wäre der zertifizierte Zyxel XMG3927 resp. gewesen.

Wie bereits erwähnt kann ich “Outbound” keine Probleme mit Latenzzeitschwankungen resp. regemässigen Mustern feststellen (tick.switch.ch, 1 s) resp. das Verhalten ist immer noch deutlich besser als über DOCSIS (schwarz markierter Bereich => DOCSIS von Sunrise-UPC):

Ich werde jetzt testweise wieder die Internet Box 2 in Betrieb nehmen und diese über einen exposed host (fälschlicherweise oft als “DMZ-Modus” benannt) in einer Double NAT Konfiguration an meine OPNsense Instanz anbinden.

millernet

Für mich ist der Fall jetzt abgeschlossen. Ich kann zwischen Vigor 166 (Modem- resp. Bridge-Mode) und IB 2 (exposed Host) wesentlichen Unterschiede erkennen. Der Vigor weisst bei Thinkbroadband regelmässige Muster auf, die IB2 nicht, hat aber tendenziell mehr und höhere Peaks.

Auch über Nacht im idle Betrieb gibt es sporadisch Spitzen bei der IB2:

Diese Peaks zeigen sich auch bei der Thinkbroadband-Messung.
Links Vigor 166, rechts Swisscom / Wingo IB 2

roterblauwal

Sorry langsam versteh ich hier auch leider nur ziemlich viel Bahnhof - die Probleme treten natürlich weiterhin auf (eben wieder 3 mal nacheinander, hat vll wirklich was mit der Uhrzeit zu tun) und ich bin weiterhin der Meinung es liegt an der Route nach London zu diesem Server da ich aus 10 Spielen mit VPN (London) das Problem nicht hatte

roterblauwal

Heute war meine letzte Weekend League - 8 Disconnects alle als Niederlage und als gespielt gewertet.
So sah der Thinkboardband chart aus:

Frage noch einmal bei EA nach ob sie etwas tun können ansonsten werde ich wohl das einfachste machen und einfach das Game deinstallieren und bei der nächsten Gelegenheit den Anbieter wechslen. - Merci für eure bisherigen Kommentare.

« Vorherige Seite