In diversen Online-Speed-Tests wird neben der Up- und Downloadrate auch die Pingzeit gemessen. Wie ich das verstanden habe wird beim Ping-Test ein bestimmtes Datenpaket vom PC als Anfrage an einen Server geschickt, der als Antwort nach einer Bearbeitungszeit ebenfalls ein Datenpaket als Antwort zurückschickt. Die dafür benötigte Zeit ist die Ping-Zeit. Was mich stutzig macht: Up- und Downloadrate werden ebenfalls ermittelt. Wenn ich nun die Dateigröße des Ping-Paketes weiß, kann ich doch mit Hilfe der Up- und Downloadzeit, die "minimale" Pingzeit berechen, unter der Annahme, das der Server sofort antwortet. Für die "normal gemessene" Pingzeit müsste doch dann folgende Formel näherungsweise gelten: Pingzeit= (Pingpaketgröße/Uploadgeschwindigkeit) +BearbeitungszeitDesServers +(Pingpaketgröße/Downloadgeschwindigkeit) Wenn die obige Formel so stimmen würde, würden bereits gemessene Up- und Downloadrate (abhängig von der Antwortzeit eines Servers) doch alleine schon ausreichen, um die Pingzeit zu berechnen. Warum wird die Pingzeit dann trotzdem extra gemessen?
Peter schrieb: > Warum wird die Pingzeit dann trotzdem extra gemessen? stell dir ein LKW mit Festplatten vor der von A nach B fährt. Wenn er nach 1 Stunde ankommen ist hat er mehrere 100GB/s übertragen. Aber die Pingzeit war nicht so gut.
Nachtrag: Wenn man 10Byte in 10 Sekunde übertragen kann, heißt das nicht das man 1 Byte in einer Sekunde übertragen kann.
Richtig, um das Bild gänzlich zu verkomplezieren: Ping ist ja oberhalt der IP-Schicht (Layer 3 ?): DAs heist du gehst zur Poststelle und stellst denen ein Packet hin mit Angabe wohin und woher: Nun liegt erstmal das Packet unbeckante Zeit in der Poststelle, dann wird es mit dem Postauto/zu Fuß/Drohne/etc. zur Nächsten Sammelstelle getragen, dort wird es Ausgeladen sotiert wohin es muss (also der Switch) wenn die Addresse nicht von der Sammelstelle erreichbar ist wird es zum Verteilzentrum Geschickt (also Router) sotiert, gelagert, verladen, transportiert ...... es kommt beim Empfänger an, von dort wird es geöffnet und drin steht ich bin ein ICMP packet der Empfänger verarbeitet das Packet und schickt dir die Antwort über den Oberen pfad (halt rückwärts) zurück. die Zeit die Zwischen deinem Abschicken und dem Empfang bei dir Liegt, ist die "ping" Dauer, bzw. RoundTripTime. MfG ich
ich schrieb: > die Zeit die Zwischen deinem Abschicken und dem Empfang bei dir Liegt, > ist die "ping" Dauer, bzw. RoundTripTime. Kurze Vervollständigung: Ob du jetzt ein Paket oder fünf da hinstellst, macht für die Transportzeit keinen großen Unterschied. Es dauert bei fünf Paketen nicht automatisch fünfmal so lange.
Rolf Magnus schrieb: > Kurze Vervollständigung: Ob du jetzt ein Paket oder fünf da hinstellst, > macht für die Transportzeit keinen großen Unterschied. Es dauert bei > fünf Paketen nicht automatisch fünfmal so lange. Die fünf Pakete werden aber bestenfalls parallel übertragen und nicht seriell.
N. A. schrieb: > Die fünf Pakete werden aber bestenfalls parallel übertragen und nicht > seriell. Da brauchst du aber viele Datenleitungen :-))
Angehängte Dateien:
-
ping.png
12 KB
Rolf Magnus schrieb: > Kurze Vervollständigung: Ob du jetzt ein Paket oder fünf da hinstellst, > macht für die Transportzeit keinen großen Unterschied. Da kann man aber Überraschungen erleben, siehe Bild. Ich habe auch einige Zeit gesucht, bis ich draufgekommen bin: das ist mein Snartphone, das ist zwar eingebucht im WLAN, muss aber anscheinend erst aufwachen. Georg
Das ist der WLAN-Sparmodus, es wird nur "selten" der Empfang angeschaltet. Auf dem WLAN-Layer gibt es ja auch nochmal ACKs. Da wird das Paket vom AP solange wiederholt, bis das Gerät das mitbekommen hat und das ACK zurückschickt.
Die Antwortzeit vom Server ist, wenn das nicht gerade ein Windows XP oder ein Rechner mit USB Netzwerkadapter ist, meistens völlig vernachlässigbar. Was Du da misst ist die Zeit die das Paket zum Ziel und wieder zurück braucht, und ja, die kleinste Zeit hier ergibt sich durch die Datenrate und die Paketgröße. Pings schickt man üblicherweise mit grob 100 Octets ab (hängt davon ab wie viel Header dazu kommt und welches Ping man verwendet) Macht also grob 800 Bits. Bei einer 300 bps Verbindung misst man also Zeiten von mindestens 2*800*300bps=5,3s. Bei ISDN hatte man 64000 bps, also Pingzeiten von mindestens 2*800/64000 was den 25 Millisekunden entspricht, die man damals hatte. ADSL hat heute aber mehr, das liegt daran, dass dort Interleaving passiert, sprich man wartet darauf, dass n Pakete kommen, fügt zu jedem Paket Fehlerkorrekturinformationen hinzu, und "mischt" die Pakete. Hat man jetzt eine kurze Störung auf der Leitung, so werden hintereinander liegende Bits gestört. Wäre diese Störung in einem Paket, so würde die Fehlerkorrektur nicht ausreichen um sie zu beheben. Dadurch dass aber die Pakete "gemischt" wurden, wird jedes minimal beschädigt, was repariert werden kann. Das war damals als ADSL konzipiert wurde wichtig, da man ja damit nicht Internet sondern "Interaktives Fernsehen" machen wollte, und da konnte man nicht einfach ein Paket neu verschicken.
Georg schrieb: > Da kann man aber Überraschungen erleben, Solche Effekte gibt es, wenn die Datenverbindung erst auf Anforderung aufgebaut wird. Was beispielsweise auch bei VPNs auftreten kann. Anfangs geht ggf. was in die Fritten, dann kommen 1-2 Langläufer und danach flutscht es.
ich schrieb: > Ping ist ja oberhalt der IP-Schicht (Layer 3 ?): Das ist falsch. Ping basiert auf ICMP Echo, und ICMP ist ein Bestandteil von IP und befindet sich somit auf derselben Protokollschicht befindet wie IP. Angesichts der Tatsache, dass dieser Sachverhalt völlig unmissverständlich im RFC792 dargestellt ist, handelt es sich bei Deiner Behauptung also um eine klare Lüge. > muss (also der Switch) In einem IP-basierten Netzwerk muss es keinen Switch geben. Es könnte sich auch um Hubs oder Direktverbindungen von Netzwerkschnittstellen handeln. > über den Oberen pfad (halt rückwärts) zurück. Der Pfad in Gegenrichtung muss nicht zwingend mit dem Pfad für die Hinrichtung übereinstimmen.
Andreas Schweigstill schrieb: > ich schrieb: >> Ping ist ja oberhalt der IP-Schicht (Layer 3 ?): > > Das ist falsch. > > Ping basiert auf ICMP Echo, und ICMP ist ein Bestandteil von IP und > befindet sich somit auf derselben Protokollschicht befindet wie IP. > Angesichts der Tatsache, dass dieser Sachverhalt völlig > unmissverständlich im RFC792 dargestellt ist, Dort ist beschrieben, daß es sich um einen integralen Bestandteil von IP handelt in dem Sinne, daß es von jedem IP-Stack implementiert sein muß, sich aber durchaus wie eine eigene Protokollschicht verhält. Andreas Schweigstill schrieb: > handelt es sich bei Deiner Behauptung also um eine klare Lüge. So eine Anschuldigung sollte man nicht leichtfertig aussprechen und ist in diesem Fall auch mit Sicherheit falsch.
Das TCP/IP Sammelsurium wurde nicht streng nach dem OSI Schichtenmodell entwickelt und passt nicht exakt dazu. Da ICMP als integraler Teil der Definition des Schicht 3 Protokolls IP rüberkommt, aber eindeutig oberhalb von ebendiesem liegt, landet man wahlweise in sowas wie Schicht 3,5 - oder eben in 4, zumal keine anderen Schicht 4 Protokolle darauf aufbauen. Damit wäre dann IP nur eine von vielen TCP/IP Definitionen, die mehrere Schichten umfassen.
:
Bearbeitet durch User
Das geht, aber nur in gewissen Grenzen. Man kann beim Ping festlegen wie groß das Paket sein soll, wenn man die größtmögliche Größe nimmt und ausreichend viele Pingzeiten mittelt und mit bekannten Werten vergleicht dann kann man zum Beispiel in einem LAN grob abschätzen ob ein anderer Rechner im selben LAN immer noch mit 54MBit/s angebunden ist oder ob der wireless Link wieder schwächelt und er nur noch mit 1MBit/s erreichbar ist. Man kann auch noch gut einen 100MBit von einem 1GBit unterscheiden, das wird aber umso unzuverlässiger je größer der Anteil der Laufzeit an der Pingzeit wird, wenn also noch ein paar Router dazwischen liegen wird das unzuverlässig.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.