Discord und einige Games laggen seit gesternt extrem

[pufferueberlauf]

seit Samstag hab ich das Problem das bei Destiny 2, ESO und FF14 Lags und disconnect ständig auftreten.

Wenn das selektiv nur fuer diese Spiele auftritt, nicht jedoch bei anderen Spielen zur selben Zeit, koennte das auch am Routing/Peering Deines ISPs liegen. Das laesst sich relativ leicht austesten indem man ein VPN zwischenschaltet, das sowohl mit dem eigenen ISP als auch mit dem Netz in dem die Spieleserver angesiedelt sind gut verbunden ist. Das ist natuerlich keineswegs die einzige moegliche Ursache, aber halt eine die durchaus schon mal vorkommt.

 

[Cl4whammer!]

Probier doch mal nen anderen DNS Server, klingt irgendwie für mich nicht nach nem Router-Problem

Mit dem DNS Server von Google wirds nicht schneller.

Wenn das selektiv nur fuer diese Spile auftritt, nicht jedoch bei anderen Spielen zur selbe Zeit, koennte das auch am Routing/Peering Deines ISPs liegen. Das laesst sich relativ leicht austesten indem man ein VPN zwischenschaltet, das sowohl mit dem eigenen ISP als auch mit dem Netz in dem die Spieleserver angesiedelt sind gut verbunden ist. Das ist natuerlich keineswegs die einzige moegliche Ursache, aber halt eine die durchaus schon mal vorkommt.

Klingt so ein wenig danach, hab mal nen tracert zu der ff14 ip geschickt die mir der Resourcenmonitor anzeigt:

Routenverfolgung zu 195.82.50.59 über maximal 30 Hops

1 <1 ms <1 ms <1 ms 192.168.1.254
2 7 ms 6 ms 6 ms 100.124.1.9
3 6 ms 6 ms 6 ms 100.127.1.133
4 7 ms 7 ms 7 ms 100.127.1.131
5 12 ms 9 ms 10 ms 185.22.46.129
6 7 ms 6 ms 7 ms ddf-b2-link.ip.twelve99.net [62.115.38.12]
7 * * * Zeitüberschreitung der Anforderung.
8 * * * Zeitüberschreitung der Anforderung.
9 12 ms * 12 ms kddi-ic319844-ffm-b1.ip.twelve99-cust.net [62.115.32.106]
10 12 ms 14 ms 13 ms 195.82.61.14
11 * * * Zeitüberschreitung der Anforderung.
12 13 ms 14 ms 13 ms 195.82.50.59

Ich denke mal die Zeitüberschreitungen sind nicht so gut oder?

 

[Drewkev]

Ich denke mal die Zeitüberschreitungen sind nicht so gut oder?

Nö, und die liegen beim ISP.

 

[Elzo]

Zieh mal das Netzkabel von dem Router und lasse ihn ausgeschaltet für min.5 Minuten , besser 10 Minuten und dann versuch es noch einmal. Schreib aber mal hier rein wenn du eine Lösung gefunden hast. Viel eben ein , als ich dachte mein Router wäre wieder defekt. Nach dem Kabel ziehen habe ich jetzt keine Probleme mehr , gut 6 Monate her

 

[Cl4whammer!]

https://allestörungen.de/stoerung/deutsche-glasfaser/

Man lese sich mal die Kommentare seit Samstag durch, ist wohl definitiv was kaputt...

 

[Elzo]

Auch wenn es hart klingt, Hauptsache ist bei dir nichts kaputt, ist billiger

 

[pufferueberlauf]

Ich denke mal die Zeitüberschreitungen sind nicht so gut oder?

Zeitueberschreitungen von Zwischenschritten sind eher egal/normal, solange der Endpunkt zuverlaessig antwortet ist alles im Lot (bzw. ist das kein brauchbares Indiz). Viele "Hops" auf einem Netzwerk-Pfad sind Geraete die primaer fuer's Datenschaufeln eingesetzt werden, die Beantworten Problemfaelle wie TTL-exceeded dann oft nur mit der langsamen CPU (und nicht mit dem schnellen ASIC) und wenn die CPU anderes zu tun hat, dann werden Dinge wie ICMP-Antworten zu generieren schon mal ganz fallen gelassen.

Im Peeringthread gibt es ein paar Postings zur (versuchten) Messung und Interpretation von Peering-bedingten Problemen. Kurz am besten mit mtr oder WinMTR arbeiten und mehr als nur 3 Messwerte aufnehmen (3 ist der Standard fuer Traceroute). Hier ein Link zu einem englischen Dokument zum Thema: https://archive.nanog.org/sites/default/files/10_Roisman_Traceroute.pdf...

 

[Drewkev]

Vielleicht hilft auch der TCP Optimizer?

 

[Holzkopf]

Gestern und Abend hört sich schon stark nach Überlastung an.
WinMTR was @pufferueberlauf erwähnt hat wäre eine gute Möglichkeit.
bekommst du Hier

Am besten mal Morgens und Abends ~12Uhr laufen lasen bis jeweils 100+ bei Sent/Recv zusammen gekommen sind. Und dann mal posten

Was auch interessant wäre, ob das Problem morgen wieder auftritt.
Gerad am WE sind angehende Überlastungen eher zu merken als unter der Woche.

 

[Cl4whammer!]

Hab 3x 15min gemessen (An FF14 Server). Um 9,12 und gerade ebend um 20 Uhr. Man sieht auf jeden Fall nen Unterschied zwischen Morgens/Mittags und Abends...

Die Lags sind heute aber in FF14 etwas weniger, Discord hört sich immernoch schlecht an.

 

[pufferueberlauf]

Das einzige was mir auffällt ist, dass im ersten Plot 12% Verlust am letzten Hop krass ist, die RTTs zum letzen Hop sind IMHO ansonsten quasi identisch*... Hast Du zufaellig einen Linux-Host oder eine Linux-VM zur Hand? Waere interessant statt ICMP auch al UDP und TCP Proben zu verwenden (unter Unixen kann mtr das)...


*) Aber fuer vermurkstes Spiel reicht hoher Loss natürlich auch aus... uebrigens Square-Enix ist angeblich dabei seine Datencenter in Europa fuer FF14 auszubauen kann theoretisch sein, dass der Engpass bei den Servern liegt (aber ich habe selber nie On-line Spiele gespielt und daher exakt 0% echte Ahnung/Erfahrung erster Hand).

 

[Cl4whammer!]

Ja ich hätte einige UbuntuVMs zur Hand, solange wir nix verbotenes machen würd mich das auch mal intressieren. Meinst du das Tool hier -> https://wiki.ubuntuusers.de/MTR/ ?

btw so schrottig kann FF14 nicht sein, da geht wenigstens der Login . Bei ESO komme ich gerade garnicht rein. Hab mal auch die ESO Server ne Zeit mit WinMRT angetestet ->

Sieht so aus als kämen die EU-Sever von beiden Anbietern btw aus Frankfurt/Düsseldorf.

 

[pufferueberlauf]

Ja, mtr, z.B. fuer kontinuierliche Ueberwachung (im Beispiel 8.8.8.8 aber erstetze das durch fuer Dich relevanten IP-Adressen):

mtr -ezb 8.8.8.8

oder wenn es fuer einen bregenzten Zeitraum sein soll (hier 5 Minuten, bzw. 300 Sekunden, Ausbaber erfolgt erst nach den 500 Sekunden, wenn das zu lange dauert, einfach die Zahl hinter dem -c reduzieren)

mtr -ezbw -c 300 8.8.8.8

Wenn es UDP Proben sein sollen:

mtr -ezbw -u -c 300 8.8.8.8

Wenn es TCP Proben sein sollen:

mtr -ezbw -T -c 300 8.8.8.8

Bei UDP/TCP kann man noch mit der Portnummer spielen:

mtr -ezbw -T --port 80 -c 300 8.8.8.8

Fuer IPv6 dann:

mtr -ezbw -6 -T --port 80 -c 300 8.8.8.8

Und Dein ESO Beispiel von O2 aus (Telekom-L3-BSA, VDSL100):

root@turris:~# mtr -ezbw -4 -c 100 159.100.232.23
Start: 2022-04-04T21:59:07+0200
HOST: turris                                                                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS6805   loopback1.0002.acln.01.ham.de.net.telefonica.de (62.52.200.148)      0.0%   100    8.6  30.2   8.4 139.4  30.9
  2. AS6805   bundle-ether28.0005.dbrx.01.ham.de.net.telefonica.de (62.53.12.16)   1.0%   100    9.1   8.9   8.6   9.9   0.2
  3. AS6805   ae4-0.0001.corx.06.ham.de.net.telefonica.de (62.53.14.230)           0.0%   100   15.6  15.6  15.2  18.1   0.4
       [MPLS: Lbl 16601 TC 0 S u TTL 1]
  4. AS6805   ae6-0.0002.corx.02.fra.de.net.telefonica.de (62.53.0.49)             0.0%   100   15.7  15.7  15.2  18.7   0.6
       [MPLS: Lbl 16601 TC 0 S u TTL 1]
  5. AS6805   bundle-ether1.0004.dbrx.02.fra.de.net.telefonica.de (62.53.14.183)   0.0%   100   16.1  16.0  15.6  16.7   0.2
       [MPLS: Lbl 16601 TC 0 S u TTL 1]
  6. AS6805   bundle-ether2.0004.prrx.02.fra.de.net.telefonica.de (62.53.8.189)    0.0%   100   16.0  16.2  15.7  17.4   0.2
  7. AS12956  176.52.252.28 (176.52.252.28)                                        0.0%   100   59.2  34.0  15.8 115.8  16.8
  8. AS3320   80.157.130.129 (80.157.130.129)                                      0.0%   100   16.1  16.2  15.6  17.3   0.3
  9. AS3320   pd900c956.dip0.t-ipconnect.de (217.0.201.86)                         0.0%   100   16.4  16.6  16.2  18.2   0.3
 10. AS3320   80.156.160.98 (80.156.160.98)                                        0.0%   100   16.1  16.4  15.6  32.5   1.8
 11. AS202167 195.122.154.4 (195.122.154.4)                                        0.0%   100   16.1  16.4  16.1  17.9   0.2
 12. AS202167 159.100.232.23 (159.100.232.23)                                      0.0%   100   16.0  16.1  15.8  17.6   0.2

Deine "ESO-IP" ist bei mir ueber die DTAG angebunden... wenn das bei Die genau so ist wuerden mich da die Probleme nicht wirklich wundern, die DG scheint keine direkte Uebergabe zur DTAG zu haben (zumindest laut https://radar.qrator.net/as60294/peerings#startDate=2022-01-04&endDate=2022-04-04&tab=current), und ueber Transit ist das DTAG-Natz zu Stosszeiten oft schlecht zu erreichen. Da kann aber ein VPN mit guter Verbindung zur DTAG helfen....

 

[shavenne]

Die selben Probleme hier seit Samstag bei Deutsche Glasfaser. Gibt auch schon auf anderen Social Media Plattformen einige Berichte. Ich vermute das betrifft schlicht alle DG-Kunden. Die Deutsche Glasfaser scheint sich dazu auszuschweigen und so zu tun, als wüsste sie von nichts... nicht überraschend.

Alles was so in Richtung bzw. durch Frankfurt geht, läuft mistig. Bei meinem Versuch das ganze per NordVPN über Amsterdam zu routen, lief das auch nicht so dolle, obwohl die DG auch eine Anbindung zu AMS-IX hat. AMS-IX ist also evtl. auch betroffen (habs nicht näher gecheckt). Gut laufen tut Brüssel über NordVPN. Damit ist der Packet Loss weg.
Gar keine Probleme hab ich zu Servern in Düsseldorf z.B.

 

[pufferueberlauf]

Interessant, dass die RTT nur sehr milde ansteigt während die Verlustrate in unerquickliche Hoehe steigt.

 

[shavenne]

Sieht so aus, als sei es um Punkt 15 Uhr gefixt worden.

 

[Holzkopf]

War wohl mal wieder einer Überlastung im DG-Netz nicht die erste und sicherlich auch nicht die Letzte..
Frag mich nur warum sie es immer erst soweit kommen lassen...

Interessant, dass die RTT nur sehr milde ansteigt während die Verlustrate in unerquickliche Hoehe steigt.

Ja Packete droppen ist ein "gutes" mittel um zu verhindern das ein Puffer voll läuft.
Das macht die Telekom auch so an einigen ihrer überlasteten T-1 Peerings.

 

[Cl4whammer!]

Die selben Probleme hier seit Samstag bei Deutsche Glasfaser. Gibt auch schon auf anderen Social Media Plattformen einige Berichte. Ich vermute das betrifft schlicht alle DG-Kunden. Die Deutsche Glasfaser scheint sich dazu auszuschweigen und so zu tun, als wüsste sie von nichts... nicht überraschend.

Anhang anzeigen 1204712

Anhang anzeigen 1204713

Alles was so in Richtung bzw. durch Frankfurt geht, läuft mistig. Bei meinem Versuch das ganze per NordVPN über Amsterdam zu routen, lief das auch nicht so dolle, obwohl die DG auch eine Anbindung zu AMS-IX hat. AMS-IX ist also evtl. auch betroffen (habs nicht näher gecheckt). Gut laufen tut Brüssel über NordVPN. Damit ist der Packet Loss weg.
Gar keine Probleme hab ich zu Servern in Düsseldorf z.B.

Womit erstellt man den die obere Grafik, sieht nice aus!

War wohl mal wieder einer Überlastung im DG-Netz nicht die erste und sicherlich auch nicht die Letzte..
Frag mich nur warum sie es immer erst soweit kommen lassen...

Was heißt hier war?

Sauge zwar gerade mit FULLSPEED auf Steam DCS World (+200GB mit 45,2 MB/s) aber gespannt was mich gleich in FF14 erwartet... Wenns immernoch schlecht ist werd ich mal auf meiner UbuntuVM mal das MTR dort durchtesten lassen.

EDIT: Tatsache, scheint jetzt wieder sehr viel besser zu sein. Dann gibt es auch erstmal nix zu testen.

 

[shavenne]

Das ist Grafana mit einer InfluxDB dahinter und Telegraf als "Datenlieferant".

 

[Holzkopf]

sagt mal habt ihr das zu mir nun rübergeschoben ?