Packet loss durch router oder Provider?

Die Pingplotter Traces sehen allesamt großartig aus. Da sind keinerlei Probleme zu sehen. Ganz im Gegenteil, ich habe selten so saubere Traces gesehen.

Wenn du zu der Zeit, wo diese Traces aufgezeichnet wurden, Probleme hattest, dann können wir dein Heimnetz und den Internetzugang ausschließen. Bleiben Peering und die Server, die du verwendest. Das nächste Mal solltest du als Ziel den Server angeben, zu dem du Probleme feststellst. Dann können wir einschätzen, ob es dort Probleme gibt.
 
  • Gefällt mir
Reaktionen: Der Lord, Raijin und Lawnmower
Gameboy9192929 schrieb:
An anderer Stelle habe ich gestern versucht, PingPlotter einigermaßen verständlich zu erklären: Klick!

Das, was du hier zeigst, ist zu 100% in Ordnung, aus den Gründen, die ich im besgaten Beitrag darlege.
Kurz gesagt: Wenn bei PingPlotter in der letzten Zeile - beim Ziel - alles in Ordnung ist, dann ist die gesamte Messung in Ordnung. Etwaige rote Stellen, hohe Latenzen oder gar Paketverluste irgendwo darüber, spielen tatsächlich keine Rolle, wenn die Messung am Ziel ok ist.
 
  • Gefällt mir
Reaktionen: Lawnmower, snaxilian und xexex
und ist das auch normal? wieso habe ich jetzt zum beispiel viel mehr hops als wie gestern? und was bedeutet diese ip adresse bei der die paketverluste auftreten?
Screenshot (21).png
 
Gameboy9192929 schrieb:
und ist das auch normal?
ja! siehe hier - wirklich eine super anschauliche Erklärung von @Raijin
und wie bereits beschrieben, Routen ändern sich - oder am verlinkten Beispiel: mal nimmt der Postbote eine andere Strecke, wenn diese in Summe schneller ist oder sonst Baustellen im Weg sind.

dein Trace zu google ist die ganze Zeit super. Finde lieber die Spielserver raus und setze dort mal Messungen an!
 
  • Gefällt mir
Reaktionen: Lawnmower
Gameboy9192929 schrieb:
wieso habe ich jetzt zum beispiel viel mehr hops als wie gestern?
Zum einen durch dynamisches Routing, zum anderen durch Domains mit mehreren IP-Adressen dahinter zwecks Lastverteilung. Schau dir mal an welche IP-Adresse google.com jeweils hat - sie unterscheiden sich in beiden Messungen. Morgen kann es wieder eine andere sein, 10 Minuten später noch eine und so weiter. Das kann sich sogar von Sekunde zu Sekunde ändern.

Selbst dieselbe IP müsste aber nicht zwingend bedeuten, dass da derselbe Server hintersteckt. Das funktioniert technisch zwar etwas anders, abereder google DNS 8.8.8.8 hat beispielsweise stets diese IP, aber es gibt zig DNS-Server über den Erdball verteilt, um die jeweilige Entfernung und damit die Antwortzeiten möglichst niedrig zu halten.
Stünde der google-DNS 8.8.8.8 nur in den USA, wäre er für uns hier in Deutschland quälend langsam...


Gameboy9192929 schrieb:
und was bedeutet diese ip adresse bei der die paketverluste auftreten?
Das bedeutet schlicht und ergreifend, dass eben dieser Hop von direkten Pings auf ihn "genervt" ist und sie bewusst verzögert oder gar nicht beantwortet, um nicht von seiner Hauptaufgabe, dem Routing, abgelenkt zu werden.

Um es deutlicher zu formulieren:

Wenn dieser Hop, der zum Zeitpunkt der Messung mutmaßlich eine höhere Auslastung hatte, alle deine Pings sofort und ohne einen auszulassen beantworten würde, entstünden bei anderen Internetnutzern auf dieser Route durch das Internet plötzlich tatsächlich Paketverluste, Pingspikes, Lags, also auch am Ziel, weil eben dieser Hop von deinen Pings in seiner Hauptaufgabe behindert wurde.
 
  • Gefällt mir
Reaktionen: Lawnmower
so, ich melde mich noch einmal. ich habe etwas bemerkt, undzwar dass wenn draußen unwetter ist schmiert meine leitung heftig ab (latenz nur), es war gerade gefühlt unmöglich einen stream bei twitch anzuschauen, deswegen habe ich mal twitch angepingt und das sieht doch nicht normal aus? der letzte hop sieht zwar normal aus aber es hat alle 10 sekunden im stream gelaggt. ich habe eine 250k dsl leitung bei telekom, wieso passiert das gerade bei unwetter?
Screenshot (22).png
 
Das sieht schon wieder sehr gut aus. Kein Packet Loss, Ping im grünen Bereich. Daran liegt es nicht, wenn twitch gestockt hat.
 
  • Gefällt mir
Reaktionen: Raijin
Nur um das mal klarzustellen: PingPlotter alias Traceroute kann einzig und allein Latenzprobleme auf einer Route durch das Internet aufdecken, nicht mehr und nicht weniger. Wenn die Latenz nicht für die Probleme verantwortlich ist, ist PingPlotter nicht das richtige Werkzeug zur Diagnose. Ein Blutdruckmessgerät eignet sich ebensowenig zum Fiebermessen.

Hinzu kommt, dass PingPlotter auch nur mit dem ICMP-Protokoll misst, also dem Ping-Protokoll, wenn ich das mal so ausdrücken darf. Auch das kann durchaus anders durch die Route laufen als ein anderes Protokoll. Eine zugegebenermaßen schlechte Analogie wäre Stille Post auf Deutsch vs auf Spanisch, wenn mittendrin jemand sitzt, der nur mäßig spanisch spricht - aber ich denke es ist klar was gemeint ist.

Wenn Streams stocken, kann es beispielsweise an der Bandbreite des Anschlusses oder am Peering des Provkders liegen. Letzteres ist sozusagen die Anbindung des Providers selbst an das Ziel. Sind zu viele Kunden auf denselben Plattform unterwegs - zB Twitch - und die Leitung des Providers dahin ist zu knapp bemessen, fängt es bei den Kunden an zu laggen.
Leider ist sowas nur schwierig zu diagnostizieren, weil man theoretisch eine Bandbreitenmessung zu Twitch machen müsste.

Wie dem auch sei, wenn das Wetter augenscheinlich Einfluss auf die Qualität der Internetverbindung als solche hat, würde ich das Problem eher in der Elektrik im Allgemeinen verordnen, Störungen, etc.
 
  • Gefällt mir
Reaktionen: redjack1000 und Lawnmower
Raijin schrieb:
Wenn Streams stocken, kann es beispielsweise an der Bandbreite des Anschlusses oder am Peering des Provkders liegen.
Das führt aber in Traceroutes oder Pings üblicherweise zu starken Schwankungen in der Antwortzeit und zu Paketverlusten.

Für viel schwieriger halte ich es, das richtige Ziel für den Pingplotter zu identifizieren. Twitch arbeitet garantiert mit einem CDN im Hintergrund, und die Quelle für den stockenden Stream dürfte kaum identisch mit der IP von twitch.tv gewesen sein.

Aber auch dieses Ergebnis lässt gewisse Rückschlüsse zu. So ist der Plot absolut sauber. Deshalb vermute ich kein Problem in der lokalen Netzwerkanbindung, sondern auf Applikationsebene. Entweder war der Server überlastet, oder der Client hat ein Problem.
 
  • Gefällt mir
Reaktionen: snaxilian, Raijin und redjack1000
meine aller letzte frage jetzt, was bedeutet es wenn da steht sekunden mit fehlern (ES) und (SES)
Screenshot (24).png
 
ES steht für Errored Seconds (Sekunden mit Fehlern seit Verbindungsaufbau)
SES steht für Severly Errored Seconds (Sekunden mit vielen Fehlern seit Verbindungsaufbau)

Solange hier keine abnormal hohen Werte stehen, sind diese Angaben vernachlässigbar. Wichtiger sind die CRC-Fehler, die nicht behebbaren Fehler. Hier scheinen es entweder 0, 8 oder 9 zu sein, weil der Screenshot leider ziemlich ungünstig aufgenommen wurde. Ich tippe aber auf 0.
 
Zurück
Oben