Ping Probleme

Alvid schrieb:
Habe ich ganz oben schon geschrieben. Bin per DLAN verbunden
Ich mag blind sein, aber ich lese nichts dergleichen.

Ganz im Gegenteil:
Alvid schrieb:
(Direkt per Netzwerkkabel am PC angeschlossen)

Direkt heißt direkt

Router - Kabel - PC

und nicht

Router - PowerLANAdapter#1 ~~~ ganz viel Stromnetz ~~~ PowerLANAdapter#2 - PC
 
  • Gefällt mir
Reaktionen: brainDotExe, Wolfpac, conf_t und 2 andere
Alvid schrieb:
Habe ich ganz oben schon geschrieben. Bin per DLAN verbunden
Irgendwie sehe ich oben nichts von DLAN. Würde zu 98% sagen, dass genau da das Problem liegt. teste es, wenn möglich, mit einem langen LAN Kabel mal ohne DLAN. DLAN ist sehr störanfällig.
 
@Raijin Das mit dem Trace wollte ich auch erkären, ist nämlich wichtig zu beachten und wird viel zu oft fehlinterpretiert. Aber mir war das gerade zu viel Arbeit. Danke dafür!

Wenn Ende-zu-Ende alle schick ist, darf man sich von scheinbar schlechten Werten dazwischen nicht irren lassen.
Manche Router haben da auch ein Rate-Limit (Reply to x pings per second). Wenn man der x+1te Ping ist in dieser Sekunde ist, bekommt man keine Antwort mehr. Selbst bei PCs wird ICMP mit einem der niedrigsten Interupts geführt und kann durch andere Systemprozesse negativ beeinflusst werden. Daher ist der Ping gerne mal schlechter als Inline die Latenz im TCP / UDP Stream selbst wäre.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Raijin
Dann habe ich das mit DLAN falsch verstanden.

Habe meinen PC direkt mit dem Router per Netzwerkkabel angeschlossen
 
Alvid schrieb:
Habe ich ganz oben schon geschrieben. Bin per DLAN verbunden
Somit hast du die Fehlerquelle herausgefunden
 
  • Gefällt mir
Reaktionen: Engaged
Alvid schrieb:
Hab mir mal kurz dieses PingPlotter geladen. Ich weiß allerdings nicht wie man dort eine Diagnose Datei erstellt. Hier nach kurzer Zeit zu twitter.com:

[IMG]https://www.computerbase.de/forum/attachments/unbenannt-png.1098195/[/IMG]
schon 2-3 neu verbunden? für eine neue ip?
ping 3 zeigt ein Telekomserver der überlastet ist

kannst die ergebnisse ins clipboard laden und dann ein eine txt datei einfügen

p.s. ganz links stehen die ping counts, für die, die das program nicht kennen
 
Sc0ut3r schrieb:
ping 3 zeigt ein Telekomserver der überlastet ist
falsch. das zeigt nur, dass dieser Hop nicht immer auf Pings in Echtzeit reagiert - KANN, aber MUSS NICHT ein Anzeichen sein. Wäre dieser Server wirklich überlastet, sähe das Endergebnis bei Twitter auch entsprechend schlecht aus.

...wurde hier aber schon ausführlich in #17, #19 und #23 beschrieben. :)
 
  • Gefällt mir
Reaktionen: brainDotExe und xxMuahdibxx
Raijin schrieb:
Die absolut wichtigste Zeile eines Trace ist die letzte, das Ziel.

Jein ... Problem dabei ist ja auch das Pingplotter eigentlich eine kleine Last auf die Leitung legt und im Standard alle 2,5 Sekunden pingt ...

Dabei kann es natürlich sein das die Schwankung eines Hops nicht auf dem Rest mit übertragen werden.

Hier muss geschaut werden das bei einem Spiel die Tic Rate entscheident ist ... scheint bei Call of Duty so um die 12-20 Hz zu liegen ... also alle 0.05 Sekunden.

Natürlich kann bei solch einer Rate genau der Knoten einen starken Einfluss haben der bei einem Ping schon schlecht antwortet.

Dabei muss man aber auch immer beachten das eine Ping anfrage nicht bei jedem Netzwerkknoten Priorisiert abgearbeitet wird ... oder oft auch verworfen wird wenn anderes wichtiger ist.

daher ein deutliches Jein ...
 
Sc0ut3r schrieb:
ping 3 zeigt ein Telekomserver der überlastet ist
Nur bei direkter Verbindung, also wenn man den Telekomserver direkt anpingt. Bei seiner Hauptaufgabe - eigentlich ist es seine einzige - macht er genau das was er soll, 1:1 weiterleiten, routen.



@xxMuahdibxx : Das "Jein" gilt schon allein deswegen, weil ICMP nun mal kein TCP ist. Man vergleicht gewissermaßen Äpfel mit Birnen. Deswegen ist ein Trace im allgemeinen oder PingPlotter im Speziellen eben auch nur seeeeeeeeeeeeehr bedingt aussagekräftig. Es kann durchaus passieren, dass ICMP bis zum Ziel super durchflutscht, aber eine TCP-Verbindung behindert wird - und das muss nicht zwingend beim vermeintlich kritischen ICMP-Hop #3 sein, sondern kann auch bei einem beliebigen anderen Hop auftreten, zB Hop #5, der sich im aktuellen Trace vollkommen unauffällig zeigt.
 
xxMuahdibxx schrieb:
Natürlich kann bei solch einer Rate genau der Knoten einen starken Einfluss haben der bei einem Ping schon schlecht antwortet.

Dabei muss man aber auch immer beachten das eine Ping anfrage nicht bei jedem Netzwerkknoten Priorisiert abgearbeitet wird ... oder oft auch verworfen wird wenn anderes wichtiger ist.

Ein Ping hat nie Priorität! Entweder ein Router hat Kapazitäten frei und er antwortet oder eben nicht. Der Router soll routen und nicht auf ICMP Requests antworten...
 
  • Gefällt mir
Reaktionen: brainDotExe und conf_t
@Raijin mag sein das es ein indiz ist, wenn aber immer die gleichen telekom server probleme zeigen und man bei games scheiß ping hat, ist die aussagekraft von ping plotter sehr wohl gegeben um den übeltäter ausfindig zu machen

telekom ist in letzter zeit einfach nur grottig was das routing angeht, je nach ip läuft alles top oder der ping geht steil durch die decke

btw. mein aktueller ping bei wot liegt bei 300-600

Target Name: login.p1.worldoftanks.eu
IP: 185.12.240.75
Date/Time: 05.07.2021 10:05:44 - 05.07.2021 10:15:44

Hop Sent PL% Min Max Avg Host Name / [IP]
1 47 0 0,49 1,05 0,68 192.1
2 47 0 7,35 11,96 8,47 p3e9bf068.dip0.t-ipconnect.de [
3 47 2 8,70 2255,07 306,82 pd900cd7a.dip0.t-ipconnect.de [217.0.205.122]
4 47 0 8,23 2204,81 255,83 pd900cd7a.dip0.t-ipconnect.de [217.0.205.122]
5 47 0 8,28 12,43 8,92 80.156.161.138 [80.156.161.138]
6 47 0 8,43 26,78 9,92 bei-b1-link.ip.twelve99.net [62.115.134.194]
7 47 0 20,08 25,63 20,82 ffm-bb2-link.ip.twelve99.net [62.115.139.6]
8 47 0 20,46 39,98 21,94 ffm-b1-link.ip.twelve99.net [62.115.121.7]
9 47 0 34,27 44,41 35,18 169.254.0.18 [169.254.0.18]
10 46 100 0 0 0 [-]
11 46 100 0 0 0 [-]
12 46 100 0 0 0 [-]
13 47 0 38,03 45,97 38,60 185.12.241.2 [185.12.241.2]
14 47 0 42,17 43,41 42,67 login.p1.worldoftanks.eu [185.12.240.75]
 
Also in deinem Beispiel sehe ich nur, dass die Loginserver von WOT bei dir im Durchschnitt mit 42ms und 0% Loss antworten. 🤷‍♂️

Generell gibt es aber durchaus Peering-Probleme bei der Telekom, das stimmt. Hatte ich eine Zeit lang sehr stark bei AWS-Servern. Ist nun aber endlich besser geworden.

Wie auch immer, bevor wir uns weiter im Kreis drehen:
Alvid sollte einfach mal die IPs der Spieleserver herausfinden (mehrere Methoden wurden genannt) und dann entsprechend einige Pingtests starten - am besten parallel dazu auf den eigenen Router und auf beispielsweise Google. So kann man das Problem weiter eingrenzen und wir müssen nicht weiter herumraten. :)
 
  • Gefällt mir
Reaktionen: conf_t
Sc0ut3r schrieb:
14 47 0 42,17 43,41 42,67 login.p1.worldoftanks.eu [185.12.240.75]
Am Ende zählt nur das
Was dazwischen passiert wird erst relevant, wenn das im letzten Hop auch zu sehen ist.

Als Ergänzung zu @Der Lord:
Durchschnittlich 42,67 ms, min 42,17ms und vor allem max 43,41 ms spiegelt überhaupt nicht das dazwischen wieder was zeigt, dass die vermeintlichen "Probleme" des 3. Hops (max. 2,2 Sekunden und 2 % PL) keine Probleme sind und sich nur auf die Beantwortung von ICMP, aber nicht auf den Datendurchsatz auswirken. Gründe warum das so ist wurde zu Hauf geliefert.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Der Lord
@Der Lord echt jetzt? wenn du auf dem weg zum ziel an einer kreuzung 10 min warten musst, biste am ende trotzdem nicht schneller am ziel
 
@Sc0ut3r: Du hast Traceroute nicht verstanden.... So funktioniert Traceroute nicht, dass man die Zeiten der einzelnen Hops auf addieren kann. Es ist möglich, dass es so ist, aber es ist kein Gesetz der Logik. Nur wenn man nicht weiß wie Traceroute funktioniert glaubt man, dass das ein Gesetz der Logik wäre.

Das ist eher so du gehst zu deinem Nachbarn klingeln und wartest bis er die Tür öffnest und notierst die Zeit.
Dann gehst du nach Hause und von dort aus zum übernächsten Nachbarn und machst das gleiche, lässt also den direkten Nachbarn aus.
Dann wieder nach Hause und dann zum überübernächsten Nachbarn usw. usw.
Und einer ist nicht da (Paketverlust), oder ist alt und braucht länger (hohe Latenz), deshalb brauchst du aber beim nächsten Durchlauf nicht länger, da du dort gar nicht mehr klingeln musst.
Die Straße ist dennoch gekehrt und du kommst gut durch.

Ein ICMP Echo Request nimmt im Router einen ganz anderen Weg. Während Pakete in HW geroutet und geswitcht werden (eigene ICs) - also die CPU des Routers gar nicht durchlaufen, muss der an den Router gerichtete ICMP Echo Request von der CPU bearbeitet werden. Und dort sind dafür die niedrigsten Prioritäten gesetzt. Da kann auch mal was "Hops" gehen - frei nach dem Motto was ich heute kann besorgen verschiebe ich auf übermorgen. Durchgeleitete Pakete kommen da gar nicht hin..... Früher wäre sowas sogar ein Einfallstor für ein DDoS Attacke gewesen, da die CPUs für das Router OS echt schwachbrüstig waren und bei einem einsprechenden Floodping mit vielen Quelllen untergingen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: brainDotExe und Der Lord
Erstmal danke für die ganzen Antworten. Ich versuche gerade die IPs der Server herrauszufinden. Wenn ich jetzt in Call of Duty einem Spiel beitrete, werden mir allerdings im Ressourcenmonitor unter TCP-Verbindungen um die 8 verschiedenen ips unter call of duty angezeigt. Gibt es da noch einen Trick um die IP des Servers zu finden auf dem ich gerade spiele?
 
@Sc0ut3r : Nochmal, nein. Ein Trace kann durch fremde Netze - wie zB das Internet - maximal ein Indiz sein.

Es gibt durchaus aussagekräftige Situationen (zB ein fortsetzender Offset bei Latenz/Paketverlust) und es gibt nichtssagende Situationen. In deinem Beispiel ist letzteres der Fall, weil das Ziel mit stabilem Ping und ohne Paketverlust erreicht wird. Auch unterwegs auf den anderen Hops sind keine sich fortsetzenden erhöhten Latenzen zu verzeichnen.

Hinzu kommt, dass eine kleine Stichprobe von ~50 Paketen vieles gar nicht darstellen kann, weil Lastspitzen zu jeder Zeit, aber eben ggfs auch nur sehr sporadisch auftreten können. Wenn du den Trace nun für länger laufen lässt und bei den Hops #6-14 plötzlich auch max 2000+ auftauchen, sieht die Sache schon anders aus, weil man dann sieht, dass sich die Pingspitzen von Hop 3/4 auf die nachfolgenden Hops auswirken.



Sc0ut3r schrieb:
@Der Lord echt jetzt? wenn du auf dem weg zum ziel an einer kreuzung 10 min warten musst, biste am ende trotzdem nicht schneller am ziel
Das ist ein Denkfehler deinerseits. Ein Trace funktioniert ungefähr so:

Du fährst auf der Autobahn von Hamburg nach München. Fährst du ohne anzuhalten durch (letzte Zeile), bist du in 6h am Ziel. Volle Rastplätze können dir egal sein, weil du gewissermaßen nur dran vorbeifährst. Biegst du aber auf die Ausfahrt ein und stehst dort im vollen Rastplatz im Stau, musst du warten, während alle anderen ja nach wie vor an Ausfahrt vorbeifahren, weil sie nur "durch" wollen.

Bei einem Trace wird letztendlich nur eine Reihe von Pings zum Ziel gesendet, also eine Reihe von Autos von Hamburg nach München. Nu sagt man aber dem ersten Auto: "Fahre maximal 1 Rastplatz weit", dem zweiten "Max 2 Rastplätze" und so weiter und so fort. Allen gemein ist aber, dass sie am Ende zwingend einmal auf die letzte Ausfahrt fahren und somit im Rastplatz-Stau stecken bleiben können, während die nachfolgenden Autos vorbeifahren, weil sie ja auf den einen der nächsten Rastplätze wollen.

Es sind einfach zwei Paar Schuhe ob ein Ping an einem Hop endet oder ob er durchgeht.


Soviel zur Theorie. Natürlich kann es sein, dass ein Hop trotzdem Probleme hat bzw. verursacht, aber es geht nur darum, dass man dies anhand der vorliegenden Traces nicht dingfest machen kann. Hätte man am Ziel ebenfalls Paketverluste oder einen erhöhten Max- bzw. AVG-Ping, würde dies darauf hindeuten, dass im obigen Beispiel mit der Autobahn eben auch die "Fahre ohne Anhalten durch"-Autos doch irgendwo anhalten mussten, quasi unerwünschte Pinkelpausen inkl. Stau an vollen Rastplätzem aka langsamen Hops.



So, und nu genug von Traces und PingPlotter. @Alvid hat ja mittlerweile preisgegeben, dass er PowerLAN einsetzt und sobald PowerLAN ins Spiel kommt, ist es in 9 von 10 Fällen für die Probleme verantwortlich. Der einfachste Test ist daher ein langes LAN-Kabel vom PC zum Router ohne PowerLAN dazwischen. Ggfs sogar die PowerLAN-Adapter aus der Steckdose ziehen, um etwaige Störungen des DSL-Signals zu vermeiden. Dann ein bischen Zocken und gucken ob die Probleme weg sind oder nicht.
 
  • Gefällt mir
Reaktionen: brainDotExe, Der Lord und conf_t
Sc0ut3r schrieb:
wenn du auf dem weg zum ziel an einer kreuzung 10 min warten musst
Nö, du musst an der Kreuzung nur auf eine ICMP-Anfrage "10 Min warten", weil die eben nicht priorisiert behandelt wird und dadurch auch teils verzögert rausgegeben wird. Aber wenn du die Kreuzung nur überqueren möchtest (der Hops also nur routet statt nervige ICMP-Requests zu beantworten), geht das wie man am Endergebnis sieht wesentlich schneller.

Stell dir vor jeder Hops würde ICMP-Anfragen priorisiert beantworten, dann war's das mit schneller Echtzeitkommunikation, weil jeder Router nur noch mit Pinganfragen beschäftigt ist. ;)

Alvid schrieb:
Gibt es da noch einen Trick um die IP des Servers zu finden auf dem ich gerade spiele?
Schwierig... am besten genau gucken, zu welchem Zeitpunkt die IPs auftauchen und gehen. Sicher sind da auch einige unnötige Lobbyserver usw dabei. Sollte also eine zus. auftauchen, sobald du die Spielewelt betrittst,. wäre das ein heißer Kandidat. Damit dann so weit wie möglich eingrenzen und notfalls mit den verbliebenen IPs den Test starten. :)

Edit:
@Raijin Absolut Zustimmung - bis auf DLAN, das kommt offenbar doch nicht zum Einsatz, siehe:
Alvid schrieb:
Dann habe ich das mit DLAN falsch verstanden.

Habe meinen PC direkt mit dem Router per Netzwerkkabel angeschlossen
 
Wenn dlan im Haus läuft, kann das eben zu den getakteten hiphpings führen, vdsl und alte dlan Adapter stören sich gegenseitig
 
Der Lord schrieb:
bis auf DLAN, das kommt offenbar doch nicht zum Einsatz
Aso, das habe ich überlesen.

Zu den Game-IPs: Einfach mal alle durchtesten, ist ja kein Beinbruch, das ein paar Mal zu machen.
 
Zurück
Oben