Seltsame NTP-Antwortzeiten im LAN

12/06/2016 - 17:42 von Christian Weisgerber | Report spam
Mir ist kürzlich ein Meinberg Lantime M300 günstig in die Hànde
gefallen. Der bezieht die Zeit mit einem DCF77-Korrelationsempfànger
aus dem Äther und stellt sie per NTP im Netz zur Verfügung. So weit,
so gut.

Ich verwende den Lantime als Stratum-1-NTP-Server im LAN. Dabei
zeigt sich ein merkwürdiger Effekt: Wenn NTP-Clients Abfragen in
kurzen Abstànden schicken (z.B. 30 s), dann folgen die Antworten
prompt in etwa 0,3 ms und mit wenig Schwankung; wenn die Clients
das Pollinterval hochfahren (z.B. 1500 s), dann steigen die
Antwortzeiten drastisch an und eiern im Bereich 1..5 ms umher. Das
sieht dann so aus:

peer
wt tl st next poll offset delay jitter
172.16.0.9 ntp
* 1 10 1 1000s 1617s -1.025ms 3.022ms 2.039ms

Paketlaufzeiten von 3 ms und ein Jitter von 2 ms sind im LAN absurd.
Wie verrückt das ist, zeigt ein Vergleich mit Servern, die irgendwo
draußen im Internet stehen, aber trotzdem deutlich geringere Laufzeit-
schwankungen aufweisen:

peer
wt tl st next poll offset delay jitter
148.251.68.100 from pool de.pool.ntp.org
* 1 10 2 464s 1611s 0.211ms 22.961ms 0.574ms
217.79.179.106 from pool de.pool.ntp.org
1 10 2 1431s 1519s 0.114ms 21.127ms 0.675ms
148.251.90.84 from pool de.pool.ntp.org
1 10 2 217s 1512s -0.787ms 23.001ms 0.851ms
78.46.53.8 from pool de.pool.ntp.org
1 10 2 478s 1585s -1.007ms 22.865ms 0.427ms

Zurück ins LAN. Das Hochspringen der Antwortzeiten ist leicht zu
beobachten. Hier ein Dump des Netzwerkverkehrs auf einem Client;
die erste Spalte zeigt die Zeit in Sekunden seit dem vorherigen
Paket; die NTP-Abfragen werden einzeln in einer Schleife mit sich
verdoppelnder Wartezeit gesendet:

tcpdump: listening on em0, link-type EN10MB
1465741195.723461 172.16.0.2.27222 > 172.16.0.9.123: v4 client strat 0 poll 0 prec 0
0.000263 172.16.0.9.123 > 172.16.0.2.27222: v4 server strat 1 poll 0 prec -19 (DF)
2.029157 172.16.0.2.37843 > 172.16.0.9.123: v4 client strat 0 poll 0 prec 0
0.000283 172.16.0.9.123 > 172.16.0.2.37843: v4 server strat 1 poll 0 prec -19 (DF)
4.030969 172.16.0.2.28160 > 172.16.0.9.123: v4 client strat 0 poll 0 prec 0
0.000274 172.16.0.9.123 > 172.16.0.2.28160: v4 server strat 1 poll 0 prec -19 (DF)
8.031527 172.16.0.2.11061 > 172.16.0.9.123: v4 client strat 0 poll 0 prec 0
0.000274 172.16.0.9.123 > 172.16.0.2.11061: v4 server strat 1 poll 0 prec -19 (DF)
16.034844 172.16.0.2.6498 > 172.16.0.9.123: v4 client strat 0 poll 0 prec 0
0.000235 172.16.0.9.123 > 172.16.0.2.6498: v4 server strat 1 poll 0 prec -19 (DF)
32.037565 172.16.0.2.10025 > 172.16.0.9.123: v4 client strat 0 poll 0 prec 0
0.000295 172.16.0.9.123 > 172.16.0.2.10025: v4 server strat 1 poll 0 prec -19 (DF)
64.048513 172.16.0.2.43958 > 172.16.0.9.123: v4 client strat 0 poll 0 prec 0
0.000290 172.16.0.9.123 > 172.16.0.2.43958: v4 server strat 1 poll 0 prec -19 (DF)
128.065585 172.16.0.2.42762 > 172.16.0.9.123: v4 client strat 0 poll 0 prec 0
0.000294 172.16.0.9.123 > 172.16.0.2.42762: v4 server strat 1 poll 0 prec -19 (DF)
256.101575 172.16.0.2.6945 > 172.16.0.9.123: v4 client strat 0 poll 0 prec 0
0.000258 172.16.0.9.123 > 172.16.0.2.6945: v4 server strat 1 poll 0 prec -19 (DF)
512.174295 172.16.0.2.41798 > 172.16.0.9.123: v4 client strat 0 poll 0 prec 0
0.002086 172.16.0.9.123 > 172.16.0.2.41798: v4 server strat 1 poll 0 prec -19 (DF)
1024.314798 172.16.0.2.6017 > 172.16.0.9.123: v4 client strat 0 poll 0 prec 0
0.002209 172.16.0.9.123 > 172.16.0.2.6017: v4 server strat 1 poll 0 prec -19 (DF)
2048.600356 172.16.0.2.43287 > 172.16.0.9.123: v4 client strat 0 poll 0 prec 0
0.001618 172.16.0.9.123 > 172.16.0.2.43287: v4 server strat 1 poll 0 prec -19 (DF)

Noch eine Beobachtung: Die Antwortzeiten veràndern sich nicht global,
sondern einzeln für jeden Client-Host. Wenn Client1 Abfragen in
kurzen Abstànden schickt, sind die Antworten an Client1 schnell.
Wenn gleichzeitig Client2 ein langes Pollinterval hat, dann bekommt
Client2 langsame Antworten.

Kann sich jemand einen Reim auf dieses Verhalten machen?
Was kann sowas erklàren?

Ein naheliegender Gedanke wàre, dass irgendetwas für die Weiterleitung
der Pakete gecachet wird. Bei langen Abstànden zwischen den Abfragen
wird der Cache verworfen und es muss ein neuer Eintrag angelegt
werden. Aber nichts, was mir einfàllt (ARP, Switch Forwarding Table,
Stateful Packet Filter) kann Verzögerungen von Millisekunden erklàren.

Vielleicht liefert der Abstand zwischen zwei Abfragen, ab dem die
Antwortzeiten hochspringen, einen Hinweis? Denkste. Beim Versuch
den Wert einzugrenzen zeigt sich, dass es statt einer Schwelle einen
breiten Übergangsbereich in der Gegend von etwa 100 bis 500 Sekunden
gibt, wo die Antwortzeiten mal kurz, mal lang sind.

Ich habe auf der Clientseite einiges variiert: Betriebssystem
(OpenBSD, FreeBSD), Paketfilter an/aus, ntpd (OpenNTPD, NTP.org),
Einzelabfrage (rdate, ntpdate), Netzwerkprotokoll (IPv4, IPv6, IPv6
link-local). Nichts davon macht einen Unterschied.

Bliebe der Lantime selbst. Dem Geràt kann man sehr weit unter die
Haube schauen. Es ist ein ELX800-Einplatinencomputer mit angeflanschter
Peripherie. Darauf làuft ein kleines Linux (Kernel 2.6.15) mit
NTP.org ntpd. Eine Root-Shell ist verfügbar und prinzipiell kann
man die vollstàndige Laufzeitkonfiguration auslesen. Ich weiß aber
nicht, wo ich bei einem Linux und diesem bizarren Effekt anfangen
soll.

Mich stören weniger die seltsamen Antwortzeiten selbst, aber das
Warum bereitet mir Kopfzerbrechen.

Christian "naddy" Weisgerber naddy@mips.inka.de
 

Lesen sie die antworten

#1 Sven Hartge
12/06/2016 - 19:02 | Warnen spam
Christian Weisgerber wrote:

Kann sich jemand einen Reim auf dieses Verhalten machen?
Was kann sowas erklàren?



Das unterschiedliche Verhalten bei unterschiedlichen Clients kann ich
nicht erklàren, aber ich evtl. hilft ja folgendes für weitere
Forschungen:

Ich betreibe im Heimnetz einen Raspi2 mit GPIO-GPS-Modul als eine
interne Zeitquelle mit PPS.

Nun ist es beim RasPi ja so, dass der Netzwerk-Chip intern via USB an
der CPU hàngt und dies gerne mal eine Quelle für Verzögerungen und
Jitter ist.

Daher sollte man beim RasPi den sog. Turbo-Modus des Chips abschalten,
bei dem er versucht durch kurzes Warten mehrere Pakete in einen
USB-Transmit zu bekommen:

http://www.satsignal.eu/ntp/Raspber...otes.html, Stichwort "Reducing
the Ethernet latency"

Ich habe diese Änderung bei mir auch gemacht und kann das dort
beschriebene Verhalten bestàtigen.

Evtl. gibt es ja àhnliche Gründe, warum sich das Embeddes-Linux in
deinem Meinberg-GPS so verhàlt.

Ergebnis aktuell:

$ ntpq -pn
remote refid st t when poll reach delay offset jitter
==+192.168.100.1 .DCFa. 1 u 25 64 377 0.158 2.962 0.263
*192.168.100.10 .GPS. 1 u 46 64 377 0.280 -0.606 0.075



Sigmentation fault. Core dumped.

Ähnliche fragen