Ping Latenz Differenz mit anderem Kernel (3.x.x)

[timmey1983]

Hi,

ich habe eine Frage die vermutlich nicht ganz so einfach zu beantworten ist.

Ich habe aus Vanilla Sources testweise den Kernel 3.5.4 heruntergeladen, config kopiert und kompiliert. Installiert und alles funktioniert.

Jedoch habe ich festgestellt, dass wenn ich localhost pinge die Pingzeiten plötzlich 3 mal so hoch sind. Die Pingzeiten sind zwar kaum der Rede wert, dennoch würde ich gerne wissen, wie die Latenzveränderung zustande kommt. Vielleicht kann mir ja jemand in der Angelegenheit helfen:

Kernel 2.6.32-5-686 ->
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_req=1 ttl=64 time=0.078 ms
64 bytes from localhost (127.0.0.1): icmp_req=2 ttl=64 time=0.045 ms
64 bytes from localhost (127.0.0.1): icmp_req=3 ttl=64 time=0.036 ms
64 bytes from localhost (127.0.0.1): icmp_req=4 ttl=64 time=0.060 ms
64 bytes from localhost (127.0.0.1): icmp_req=5 ttl=64 time=0.042 ms

Kernel 3.5.4 ->
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_req=1 ttl=64 time=0.122 ms
64 bytes from localhost (127.0.0.1): icmp_req=2 ttl=64 time=0.121 ms
64 bytes from localhost (127.0.0.1): icmp_req=3 ttl=64 time=0.133 ms
64 bytes from localhost (127.0.0.1): icmp_req=4 ttl=64 time=0.112 ms
64 bytes from localhost (127.0.0.1): icmp_req=5 ttl=64 time=0.148 ms

Hatt auch mal testweise den 3er Kernel aus dem Backport installiert. Da habe ich das selbe Phänomen.

Vielen Dank und viele Grüße,
Tim

[syssi]

Ich nutze Kernel 3.5(.2) aus Experimental und habe dieses Probleme nicht. Vielleichst kannst du diese Information irgendwie verwerten.

[timmey1983]

Danke für deine Antwort. Es ist schwierig für mich herauszufinden, woran es liegen könnte. Was hast du denn für Netzwerkkarten in deinem System?

Gruß,
Tim

[cosmac]

so schaut es bei mir aus: 36670
nicht ganz so krass, aber tendenziell war früher eben alles besser...

Die Netzwerkkarte sollte allerdings keine Rolle spielen, zum localhost brauchen die ping-Päckchen den Umweg über die Hardware eigentlich nicht.

[timmey1983]

Danke cosmac,

hast du denn vielleicht eine Idee, wie ich das Thema debuggen könnte?


Gruß
Tim

[syssi]

Danke für deine Antwort. Es ist schwierig für mich herauszufinden, woran es liegen könnte. Was hast du denn für Netzwerkkarten in deinem System?

Die Netzwerkkarte ist unrelevant. Lokale Pings werden ueber das Loopback-Interface abgewickelt und laeuft in purer Software.

[Cae]

Code: Alles auswählen

3.2.0-3-amd64
64 bytes from localhost (127.0.0.1): icmp_req=1 ttl=64 time=0.073 ms
64 bytes from localhost (127.0.0.1): icmp_req=2 ttl=64 time=0.060 ms
64 bytes from localhost (127.0.0.1): icmp_req=3 ttl=64 time=0.055 ms
64 bytes from localhost (127.0.0.1): icmp_req=4 ttl=64 time=0.057 ms
64 bytes from localhost (127.0.0.1): icmp_req=5 ttl=64 time=0.056 ms

2.6.32-5-686
64 bytes from localhost (127.0.0.1): icmp_req=1 ttl=64 time=0.109 ms
64 bytes from localhost (127.0.0.1): icmp_req=2 ttl=64 time=0.055 ms
64 bytes from localhost (127.0.0.1): icmp_req=3 ttl=64 time=0.059 ms
64 bytes from localhost (127.0.0.1): icmp_req=4 ttl=64 time=0.054 ms
64 bytes from localhost (127.0.0.1): icmp_req=5 ttl=64 time=0.056 ms

2.6.32-5-amd64
64 bytes from localhost (127.0.0.1): icmp_req=1 ttl=64 time=0.035 ms
64 bytes from localhost (127.0.0.1): icmp_req=2 ttl=64 time=0.012 ms
64 bytes from localhost (127.0.0.1): icmp_req=3 ttl=64 time=0.010 ms
64 bytes from localhost (127.0.0.1): icmp_req=4 ttl=64 time=0.015 ms
64 bytes from localhost (127.0.0.1): icmp_req=5 ttl=64 time=0.011 ms

Drei unterschiedliche Maschinen, drei Standardkernel (Wheezy, Squeeze, Squeeze). Hat das nun etwas mit der Architektur zu tun? Keine nennenswerte Last auf den Kisten.

Gruß Cae

[timmey1983]

Cae, danke für deine Antwort.

Vielleicht liegt es ja wirklich an der Architektur. Guter Hinweis.

Ich werd jetzt erstmal googeln. Habe ja heute frei .

Gruß,
Tim

[Cae]

Code: Alles auswählen

% uname -r; ping -c 5 localhost | awk '(1 < NR && 7 > NR)'
3.2.0-3-amd64
64 bytes from localhost (127.0.0.1): icmp_req=1 ttl=64 time=0.040 ms
64 bytes from localhost (127.0.0.1): icmp_req=2 ttl=64 time=0.032 ms
64 bytes from localhost (127.0.0.1): icmp_req=3 ttl=64 time=0.032 ms
64 bytes from localhost (127.0.0.1): icmp_req=4 ttl=64 time=0.025 ms
64 bytes from localhost (127.0.0.1): icmp_req=5 ttl=64 time=0.025 ms

% uname -r; ping -c 5 localhost | awk '(1 < NR && 7 > NR)'
3.3.0-3-grml-486
64 bytes from grml (127.0.0.1): icmp_req=1 ttl=64 time=0.034 ms
64 bytes from grml (127.0.0.1): icmp_req=2 ttl=64 time=0.033 ms
64 bytes from grml (127.0.0.1): icmp_req=3 ttl=64 time=0.026 ms
64 bytes from grml (127.0.0.1): icmp_req=4 ttl=64 time=0.037 ms
64 bytes from grml (127.0.0.1): icmp_req=5 ttl=64 time=0.037 ms

Wieder zwei andere Kisten, die hängen beide eher im Mittelfeld.

Gruß Cae

[timmey1983]

Habe gerade mit dem Kernel amd64 getestet:

2.6.32-5-amd64:
64 bytes from 192.168.50.1: icmp_req=1 ttl=64 time=0.095 ms
64 bytes from 192.168.50.1: icmp_req=2 ttl=64 time=0.056 ms
64 bytes from 192.168.50.1: icmp_req=3 ttl=64 time=0.044 ms
64 bytes from 192.168.50.1: icmp_req=4 ttl=64 time=0.042 ms
64 bytes from 192.168.50.1: icmp_req=5 ttl=64 time=0.048 ms
64 bytes from 192.168.50.1: icmp_req=6 ttl=64 time=0.042 ms

Allerdings habe ich festgestellt, dass auch manchmal eine 0.036er Serie angezeigt wird. Aber wovon hängt das ab? Ich kann mir dann bei einem 3.5.4 Kernel nicht erklären, warum die Latenz plötzlich bei der selben Architektur fast um den Faktor 3 dauerhaft ansteigt (z.B. 1.121 ms ). Es muss doch einen "Auslöser" dafür geben. Nur...wie bekommt man das raus?

Gruß,
Tim

[unitra]

Habe gerade mit dem Kernel amd64 getestet:

2.6.32-5-amd64:
64 bytes from 192.168.50.1: icmp_req=1 ttl=64 time=0.095 ms
64 bytes from 192.168.50.1: icmp_req=2 ttl=64 time=0.056 ms
64 bytes from 192.168.50.1: icmp_req=3 ttl=64 time=0.044 ms
64 bytes from 192.168.50.1: icmp_req=4 ttl=64 time=0.042 ms
64 bytes from 192.168.50.1: icmp_req=5 ttl=64 time=0.048 ms
64 bytes from 192.168.50.1: icmp_req=6 ttl=64 time=0.042 ms

Allerdings habe ich festgestellt, dass auch manchmal eine 0.036er Serie angezeigt wird. Aber wovon hängt das ab? Ich kann mir dann bei einem 3.5.4 Kernel nicht erklären, warum die Latenz plötzlich bei der selben Architektur fast um den Faktor 3 dauerhaft ansteigt (z.B. 1.121 ms ). Es muss doch einen "Auslöser" dafür geben. Nur...wie bekommt man das raus?

Gruß,
Tim

ICMP ist best effort, wenn höher priorisierte Prozesse im linux laufen, dann muss ICMP Echo ein Wenig länger warten bis es beantwortet wird.

[Cae]

ICMP ist best effort, wenn höher priorisierte Prozesse im linux laufen, dann muss ICMP Echo ein Wenig länger warten bis es beantwortet wird.

Demnach müsste eine Shell mit hoher Priorität den ICMP-Code ausstechen:

Code: Alles auswählen

# nice
-20
# (ping -c 25 localhost &); sleep 5; stress -c 3 -t 10
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_req=1 ttl=64 time=0.033 ms
64 bytes from localhost (127.0.0.1): icmp_req=2 ttl=64 time=0.014 ms
64 bytes from localhost (127.0.0.1): icmp_req=3 ttl=64 time=0.020 ms
64 bytes from localhost (127.0.0.1): icmp_req=4 ttl=64 time=0.018 ms
64 bytes from localhost (127.0.0.1): icmp_req=5 ttl=64 time=0.015 ms
64 bytes from localhost (127.0.0.1): icmp_req=6 ttl=64 time=0.025 ms
stress: info: [4950] dispatching hogs: 3 cpu, 0 io, 0 vm, 0 hdd
64 bytes from localhost (127.0.0.1): icmp_req=7 ttl=64 time=0.023 ms
64 bytes from localhost (127.0.0.1): icmp_req=8 ttl=64 time=0.021 ms
64 bytes from localhost (127.0.0.1): icmp_req=9 ttl=64 time=0.017 ms
64 bytes from localhost (127.0.0.1): icmp_req=10 ttl=64 time=0.019 ms
64 bytes from localhost (127.0.0.1): icmp_req=11 ttl=64 time=0.031 ms
64 bytes from localhost (127.0.0.1): icmp_req=12 ttl=64 time=0.020 ms
64 bytes from localhost (127.0.0.1): icmp_req=13 ttl=64 time=0.019 ms
64 bytes from localhost (127.0.0.1): icmp_req=14 ttl=64 time=0.019 ms
64 bytes from localhost (127.0.0.1): icmp_req=15 ttl=64 time=0.017 ms
64 bytes from localhost (127.0.0.1): icmp_req=16 ttl=64 time=0.026 ms
stress: info: [4950] successful run completed in 10s
# 64 bytes from localhost (127.0.0.1): icmp_req=17 ttl=64 time=0.018 ms
64 bytes from localhost (127.0.0.1): icmp_req=18 ttl=64 time=0.014 ms
64 bytes from localhost (127.0.0.1): icmp_req=19 ttl=64 time=0.015 ms
64 bytes from localhost (127.0.0.1): icmp_req=20 ttl=64 time=0.016 ms
64 bytes from localhost (127.0.0.1): icmp_req=21 ttl=64 time=0.029 ms
64 bytes from localhost (127.0.0.1): icmp_req=22 ttl=64 time=0.019 ms
64 bytes from localhost (127.0.0.1): icmp_req=23 ttl=64 time=0.021 ms
64 bytes from localhost (127.0.0.1): icmp_req=24 ttl=64 time=0.013 ms
64 bytes from localhost (127.0.0.1): icmp_req=25 ttl=64 time=0.011 ms

--- localhost ping statistics ---
25 packets transmitted, 25 received, 0% packet loss, time 23999ms
rtt min/avg/max/mdev = 0.011/0.019/0.033/0.007 ms
uname -r
2.6.32-5-amd64
# grep -c name /proc/cpuinfo
2
# 

Diese Beobachtung würde ich schwer so deuten können.

Gruß Cae

[dufty]

Ich bin ja nicht neugierig, aber interessieren würde es mich dennoch:

Bei welcher Applikation ist es von Relevanz,
ob ein ping auf localhost 10 oder 100 mikro-Sekunden benötigt?

Danke.

[syssi]

Bei welcher Applikation ist es von Relevanz,
ob ein ping auf localhost 10 oder 100 mikro-Sekunden benötigt?

Schwarz gemalt: Wenn dein System / das Netzwerken ploetzlich Faktor 10 langsamer ist, wuerde ich mir schon sorgen machen.

[dufty]

Bei welcher Applikation ist es von Relevanz,
ob ein ping auf localhost 10 oder 100 mikro-Sekunden benötigt?

Schwarz gemalt: Wenn dein System / das Netzwerken ploetzlich Faktor 10 langsamer ist, wuerde ich mir schon sorgen machen.

Gerade eben dieses wurde vom OP nicht gezeigt.

Er hat _nicht_ geschrieben, dass pingen von z. B. 8.8.8.8 nun
statt 80 ms jetzt 0.8 s dauert.

Hingegen, wenn sich ein ping auf z. B. 8.8.8.8
von 80.010 ms
auf 80.100 ms
erhöht, ist dies, meiner bescheidenen Meinung nach, nicht relevant,
da die Streuung der Meßwerte die der "Zusatz-Latenz" bei weitem übertrifft.

[syssi]

Er hat _nicht_ geschrieben, dass pingen von z. B. 8.8.8.8 nun
statt 80 ms jetzt 0.8 s dauert.

Hingegen, wenn sich ein ping auf z. B. 8.8.8.8
von 80.010 ms
auf 80.100 ms
erhöht, ist dies, meiner bescheidenen Meinung nach, nicht relevant,
da die Streuung der Meßwerte die der "Zusatz-Latenz" bei weitem übertrifft.

Fuer dich scheint die RTT einer DSL-Leitung das Maß aller Dinge zu sein. Wenn jemand ueber die Latenz seiner DSL-Leitung klagt, dann liegt es mir fern darauf hinzuweisen, dass es fuer die Kommunikation zwischen Erde und Mond unrelevant ist.

[dufty]

Auch Protokolle (resp. ihre Implementationen) haben ihre Grenzen.
Da die Entfernung Erde-Mond größer als eine Lichtsekunde ist,
würde bereits bei einer Windows Kiste der Ping aus-time-n.
=> IPv4 unmodifiziert nicht "space-tauglich".

Nach unten gibt es ebenfalls Limitationen:
NTP kann z. B. nicht besser als 232 pico-Sekunden synchronisieren.
Selbst ein Netzwerk-stack komplett in Hardware ist nicht beliebig schnell.

Was ich schick fand:
# tc qdisc add dev lo root handle 1:0 netem delay 40msec
# ping localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_req=1 ttl=64 time=80.1 ms
64 bytes from localhost (127.0.0.1): icmp_req=2 ttl=64 time=80.1 ms
64 bytes from localhost (127.0.0.1): icmp_req=3 ttl=64 time=80.1 ms
^C
--- localhost ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 80.128/80.146/80.176/0.232 ms

Einfach bei Deinem 2.6.32-kernel mit im Startscript reinhauen und die Seele hat ihre Ruh'.

[timmey1983]

Vielen Dank für eure Antworten.

Ich hab mich nun erstmal damit abgefunden.