Methode zur Abschätzung der Latenzzeit (= latency, delay oder Entfernung in ms)

[Jason]

Zur Dimensionierung des Receive Window (RWIN) kann man hierfür einen minimalen Wert errechnen.

RWIN > Datenrate(max) x Latenzzeit (auch häufig als BDP = Bandwith * delay product bezeichnet)

Die Datenrate(max) ist die DSL-Leitungsgschwindigkeit (Nutzgeschwindigkeit).

Die Latenzzeit (Entfernung in ms, latency oder delay) ist die Zeit, die ein Datenpaket (Files und Internetseiten werden in kleine Datenpakete zerlegt, verschickt und wieder zusammengesetzt) benötigt, um von Punkt A (z.B. ein Internetserver) nach Punkt B (z.B. der heimische PC) zu gelangen, zuzüglich der benötigten Zeit für die Bestätigung zurück (=ACKnowledgement). Die Latenzzeit ist hier gleichzusetzen mit der Round Trip Time (RTT) des Datenpfades.

Die Latenzzeit wird häufig mit dem Ping verwechselt, doch es ist folgendes zu unterscheiden:
Beim Ping (in Anlehnung an das Geräusch eines Sonars) wird ein ICMP-Echo-Request-Paket an eine Zieladresse (z.B. ein entfernt stehender Rechner) gesendet. Der Empfänger (Zieladresse) sendet eine Antwort zurück, das ICMP Echo-Reply. Die dafür benötigte Zeit (für den Round Trip) wird ebenfalls in ms angegeben.
Zu beachten ist, dass das von Ping verwendete einfache ICMP-Protokoll in vielen Netzwerken anders geroutet oder priorisiert wird als der übliche TCP-Datenverkehr, weshalb die Antwortzeit des Pings nur eine grobe Orientierung sein kann für die tatsächliche Latenzzeit.

Um die RTT des Datenpfades zu bestimmen, müssen die Latenzzeiten beim Downstream und beim Upstream getrennt gemessen werden, da beim Downstrem große Datenpakete verschickt werden, während beim Upstream nur viel kleinere ACK-Pakete zurückgeschickt werden. Eine vernünftige Messung kann eigentlich nur auf der Serverseite erfolgen.

Auf der Empfängerseite kann jedoch eine intelligente Abschätzung der RTT des Datenpfades unter Zuhilfenahme des Ping vorgenommen werden.

1. Wir messen den Ping für ein datenpaketgroßes ICMP-Echo-Request-Paket.

ping -f -n 10 -l 1464 host_or_IP

Man nimmt MTU-28 als Längenparameter (-l Option), d.h. für PPPoE (1492-28 = 1464).
Für reines Ethernet nimmt man 1500-28 = 1472.
Von den 10 gemessenen Werten bleiben einzelne, allzugroße Ausreißer unberücksichtigt.

2. Für das kleinere ACK nehmen wir ein etwa ACK-großes ICMP-Echo-Request-Paket.

ping -f -n 10 -l 12 host_or_IP

3. Als Abschätzung für die Latenzzeit nimmt man nun den Mittelwert der beiden gemessenen Pings.


Ein praktisches Beispiel:


1) ping -f -n 10 -l 1464 www.speedguide.net

Pinging speedguide.net [66.230.207.58] with 1464 bytes of data:

Reply from 66.230.207.58: bytes=1464 time=161ms TTL=46
Reply from 66.230.207.58: bytes=1464 time=161ms TTL=46
Reply from 66.230.207.58: bytes=1464 time=162ms TTL=46
Reply from 66.230.207.58: bytes=1464 time=163ms TTL=46
Reply from 66.230.207.58: bytes=1464 time=163ms TTL=46
Reply from 66.230.207.58: bytes=1464 time=162ms TTL=46
Reply from 66.230.207.58: bytes=1464 time=182ms TTL=46
Reply from 66.230.207.58: bytes=1464 time=161ms TTL=46
Reply from 66.230.207.58: bytes=1464 time=162ms TTL=46
Reply from 66.230.207.58: bytes=1464 time=162ms TTL=46

Ping statistics for 66.230.207.58:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 161ms, Maximum = 182ms, Average = 163ms


2) ping -f -n 10 -l 12 www.speedguide.net

Pinging speedguide.net [66.230.207.58] with 12 bytes of data:

Reply from 66.230.207.58: bytes=12 time=146ms TTL=46
Reply from 66.230.207.58: bytes=12 time=145ms TTL=46
Reply from 66.230.207.58: bytes=12 time=146ms TTL=46
Reply from 66.230.207.58: bytes=12 time=146ms TTL=46
Reply from 66.230.207.58: bytes=12 time=145ms TTL=46
Reply from 66.230.207.58: bytes=12 time=145ms TTL=46
Reply from 66.230.207.58: bytes=12 time=146ms TTL=46
Reply from 66.230.207.58: bytes=12 time=145ms TTL=46
Reply from 66.230.207.58: bytes=12 time=145ms TTL=46
Reply from 66.230.207.58: bytes=12 time=147ms TTL=46

Ping statistics for 66.230.207.58:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 145ms, Maximum = 147ms, Average = 145ms


3) Latenzzeit = (163ms + 145ms) / 2 = 154ms

Schlußfolgerung:

Nimmt man diese Latenzzeit als Basis für die Bestimmung des RWIN, dann gilt für eine Leitung mit 16000 kbit/s:

RWIN > 16000 kbit/s x 154ms = 308000 Byte

Mit anderen Worten heißt dies, das RWIN muß größer als 308000 Byte sein, um von der Seite www.speedguide.net mit maximaler Geschwindigkeit von 16000 kbit/s downloaden zu können.

Die Latenzzeit ist bekanntermaßen von Server zu Server verschieden groß. Das praktische Beispiel zeigt aber auch, dass die Berücksichtigung einer Latenzzeit von 200ms (siehe TCP/IP Analyzer) einen Sinn macht.

Jason

[BitteEinBit]

Die Statistiken bekommt man aber mit dem normalen Ping nicht heraus, oder hab ich einen Parameter übersehen ? Z. B. der "hrping" von cfos ist vielsagender. Welchen "Ping" hast Du verwendet ? Linux ?

This is hrPING v2.38 by cFos Software GmbH -- http://www.cfos.de

Pinging www.speedguide.net [66.230.207.58]
with 1464 bytes data (1492 bytes IP):

Reply from 66.230.207.58: seq=0000 time=186.653ms TTL=45 ID=678b
Reply from 66.230.207.58: seq=0001 time=183.821ms TTL=45 ID=678c
Reply from 66.230.207.58: seq=0002 time=184.375ms TTL=45 ID=678d
Reply from 66.230.207.58: seq=0003 time=184.505ms TTL=45 ID=678e
Reply from 66.230.207.58: seq=0004 time=184.354ms TTL=45 ID=678f
Reply from 66.230.207.58: seq=0005 time=184.201ms TTL=45 ID=6790
Reply from 66.230.207.58: seq=0006 time=184.522ms TTL=45 ID=6791
Reply from 66.230.207.58: seq=0007 time=184.820ms TTL=45 ID=6792
Reply from 66.230.207.58: seq=0008 time=184.871ms TTL=45 ID=6793
Reply from 66.230.207.58: seq=0009 time=184.358ms TTL=45 ID=6794

Statistics for www.speedguide.net:
Packets: sent=10, rcvd=10, error=0, lost=0 (0% loss) in 4.684385 sec
RTTs of replies in ms: min/avg/max: 183.821 / 184.648 / 186.653

----------------------------------------------------------------------------------------

This is hrPING v2.38 by cFos Software GmbH -- http://www.cfos.de

Pinging www.speedguide.net [66.230.207.58]
with 12 bytes data (40 bytes IP):

Reply from 66.230.207.58: seq=0000 time=148.818ms TTL=45 ID=6795
Reply from 66.230.207.58: seq=0001 time=146.890ms TTL=45 ID=6796
Reply from 66.230.207.58: seq=0002 time=147.413ms TTL=45 ID=6797
Reply from 66.230.207.58: seq=0003 time=146.866ms TTL=45 ID=6798
Reply from 66.230.207.58: seq=0004 time=146.356ms TTL=45 ID=6799
Reply from 66.230.207.58: seq=0005 time=146.084ms TTL=45 ID=679a
Reply from 66.230.207.58: seq=0006 time=146.799ms TTL=45 ID=679b
Reply from 66.230.207.58: seq=0007 time=147.491ms TTL=45 ID=679c
Reply from 66.230.207.58: seq=0008 time=146.250ms TTL=45 ID=679d
Reply from 66.230.207.58: seq=0009 time=146.688ms TTL=45 ID=679e

Statistics for www.speedguide.net:
Packets: sent=10, rcvd=10, error=0, lost=0 (0% loss) in 4.646545 sec
RTTs of replies in ms: min/avg/max: 146.084 / 146.965 / 148.818

Setzbare Parameter für hrping:

-lic Show public license and warranty
-t Ping the specified host until stopped
-n count Number of echo requests to send (default 4)
-E file Stop pinging when <file> exists
-l size Send buffer size (ICMP payload size, default 64)
-L size Total IP datagram size (ICMP payload size + 28)
-f Set Don't Fragment bit in IP header
-i TTL Time To Live (default 255 for ping, 30 for traceroute)
-v TOS Type Of Service (default 0)
-w timeout Timeout in millisecs to wait for each reply (default 2000)
-s time Interval in millisecs between packets (default 500 ms)
-r [count] Be a traceroute (do <count> pings each hop, default 3)
-a [hop] Resolve addresses to names for traceroute (start at <hop>)
-o Don't do overlapped send/receive
-tsc Force RDTSC usage
-W "warm up" with one uncounted echo request at beginning
-F file Log output into <file> as well
-T Print timestamp in front of each line
-I id Set ICMP id field to <id>
-q Don't print a line per ping
-A Abort after the first echo reply (-AA => or error)
-H use IP_HDR_INCL socket option (experimental)
-S print a summary on each receive

BitteEinBit

[Jason]

Mein Beispiel wurde mit dem normalen Ping gemacht, exakt wie angegeben. Mein Betriebssytem ist Windows XP.
Ich erkenne nicht, worin das hrping für den zu ermittelnden Wert des durchschnittlichen Pings bei vorgegebenner Länge bei 10 Messungen vielsagender sein soll.

Deine gemessenen Werte ergeben ein RWIN von 330000 Bytes und der Unterschied zu meinem ermittelten Wert ist kleiner als 8%. Das bestätigt mir, dass die Methode für eine grobe Abschätzung OK ist.

Beim normalen Ping kann man übrigens auch diverse Parameter angeben:

Microsoft(R) Windows DOS
(C)Copyright Microsoft Corp 1990-2001.

Usage: ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS]
[-r count] [-s count] [[-j host-list] | [-k host-list]]
[-w timeout] target_name

Options:
-t Ping the specified host until stopped.
To see statistics and continue - type Control-Break;
To stop - type Control-C.
-a Resolve addresses to hostnames.
-n count Number of echo requests to send.
-l size Send buffer size.
-f Set Don't Fragment flag in packet.
-i TTL Time To Live.
-v TOS Type Of Service.
-r count Record route for count hops.
-s count Timestamp for count hops.
-j host-list Loose source route along host-list.
-k host-list Strict source route along host-list.
-w timeout Timeout in milliseconds to wait for each reply.

Jason

[BitteEinBit]

Ok. Dann hat Windows XP einen komfortableren Pingbefehl als NT4, aber deswegen rüst ich nun nicht auf XP um.

Gruss

BitteEinBit