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.
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.
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.
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.
