orm@doc-tcpip.org

Erstellt: Juni 2001 - Letzte Modifikation: November 2002

[ Main | Local ]


Wenn der xntpd Probleme macht


Wie es aussehen sollte

Nach dem Start erscheint im Syslog eine kurze Meldung mit Version etc. Darauf meldet sich der Client in 64 Sekunden Abständen beim Server (das kann man konfigurieren, minpoll). Nach dem er 5 gültige Antworten erhalten hat, kann er das erste Mal die lokale Uhr verändern. Es gibt einen Schwellenwert für den Zeitunterschied, der den xntpd auf dem Client dazu veranlaßt, sofort auszusteigen (1000 Sekunden, näheres weiter unten). Findet der Deamon einen Zeitunterschied zwischen Client und Server von weniger als 1000 Sekunden, aber mehr als 125 Millisekunden, so steppt der Deamon die Uhr, gleicht also in Schritten an. Bei kleineren Unterschieden erfolgt "slewing", also kleine, inkrementelle Schritte. Der Hauptunterschied ist, daß beim Stepping nach jedem Schritt wieder 5 Zeitinformationen abgewartet werden.

Fängt man mit der Hardware-Uhr als Referenz an, so sollte man nach ein bis zwei Tagen Offsets von 5 bis 10 ms haben, wenn Server und Clients in einem überschaubaren LAN stehen. Die Dispersion (also die Abschätzung des größten Fehlers. Hier fließt die Rundlaufzeit, die Präzision der Uhr und das Alter der Zeitinformation ein) sollte deutlich unter einer Sekunde liegen. Das Reach-Register sollte fast immer 377 zeigen, also es gehen keine Pakete verloren.

Im File driftfile sollte es dann etwa so aussehen: -26.525 0.033. Das ist einmal der Frequenzunterschied in parts per million (ppm) und der geschätzte Fehler dazu. Die Anzahl der CPU-Takte, die dieses System als 1 Sekunde ansieht, unterscheidet sich um diesen Wert von dem aus der Zeitinformation gewonnen Wert und stellt letztendlich die Korrektur da (wenn wir davon ausgehen, das die Frequenz des Quarzes dieses Rechners linear, also ohne Störungen, von der Vergleichs-Frequenz wegläuft, dann ist der Drift die Steigung der Gerade..). Man kann sich ausrechnen, was das heißt:

-26.525 ppm => -26.525 10^-6 => -26.525 10^-6 * 3600 * 24 * 7 = 16.042 Sekunden/Woche

Die Uhr dieses Rechners verliert also 16 Sekunden in einer Woche gegen UTC. Beide Werte sind nicht toll, aber mit der Hardware-Uhr als Referenz nicht anders zu erwarten. Als Hilfe kann man sich merken, das 12 ppm rund 7 Sekunden pro Woche sind, also eine am Tag.

Die NTP Version 4 kann bis zu 500 ppm ausgleichen, das sind 43 Sekunden am Tag (diese Version wurde speziell für WANs entwickelt; es wird auch an NTP Versionen für Sateliten gearbeitet). Die Version 3 konnte 100 ppm ausgleichen, was immer noch jenseits von gut und böse ist.

Wichtige Checks

xntpdc -c loopinfo zeigt die zusammengefaßten Offsets nach dem letzten Polling des Servers. Das ist ein Maß für den geschätzen Fehler bis zum Stratum 1 Server.

xntpdc -c kerninfo zeigt die Korrektur, die nach angewandt werden muß (ist aber nicht immer implementiert).

xtpdc -p zeigt die Offsets alle erreichbaren Server und was ntpd als aktuellen Fehler relativ zu den Servern sieht.

Dem xntpdc-Kommando ist ein eigenes Kapitel mit vielen Beispielen gewidmet...

Logging/Tracing aufsetzen

Der xntpd ist von Haus aus nicht sehr mitteilsam. Die allerwichtigsten Sachen loggt er ins Syslog, aber viel ist das nicht. Im Debug-Modus (wenn man den Deamon mit bis zu 10 "-d" startet) schreibt er mehr.

Zusätzlich gibt es zwei Bereiche, in denen er loggt - einmal alles, was mit dem eigentlichen Deamon zu tun hat. Das geht in ein definiertes Logfile. Dann kann man ihn noch ausführlich über die NTP Berechnungen loggen lassen und man kann das Handling der NTP-Pakete tracen.

Die Konfiguration für umfassendes Loggen und Trace sähe etwa so aus - allerdings sollte man vorher noch mal die Dokumentation zur Hand nehmen und zusammenstellen, was man genau braucht.

 driftfile /etc/ntp.drift

logfile   /var/log/ntp 
# logconfig =syncstatus +syncevents +peerevents +sysevents +allclock 
logconfig =all

statsdir /tmp/ 
filegen peerstats  file peerstats  type day enable 
filegen loopstats  file loopstats  type day enable
# filegen clockstats file clockstats type day enable 

Das Drift-File dient eigentlich nur dazu, das der Server nach einen Neustart schneller wieder syncronisiert wird.

Mittels des logconfig-Statements kann man genau eingrenzen, was man sehen will - was sehr hilfreich ist.

Dann kann man noch eine Reihe Statistiken erzeugen, die zur langfristingen Auswertung des Verhaltens dienen. In diesem Fall werden Informationen über den Syncronisations-Loop des Client und die Server erhoben. Die clockstats Anweisung macht nur auf einer Maschine mit angeschloßener Uhr Sinn.
Im obigen Beispiel schreibt der xntpd bei jeder seiner Anfragen die Ergebnisse in ein File. Dieses File wird täglich nachts um 00:00 Uhr mit einem Zeitstempel umbenannt.

Logging Auswerten

Loopstats auswerten

Die loopstats-Anweisung erzeugt eine regelmäßige Ausgabe der Werte, mit denen die Systemzeit "diszipliniert" wird. Es gibt verschiedene Arten, die Systemzeit über den Kernel nachzuführen. Es handelt sich aber immer um die Regelung der Frequenz und Phase über eine Schleife, daher auch die Angabe "PLL" (Phase Locked Loop).

Je nach Version des NTP wird verschieden viel mitgeschrieben. Hier ein Ausschnitt aus dem Loopstat der Verson 3:

 

52551 33870.822 -0.000166 6.2528 7 
52551 33998.823 0.000049 6.2543 7 
52551 34126.824 0.000041 6.2557 8 
52551 34254.825 0.000096 6.2588 8 
52551 34372.825 0.000109 6.2592 8 

Die einzelnen Spalten haben folgende Bewandnis:

Mit diesen Angaben kann man sich über einen längeren Zeitraum ein genaues Bild über das Verhalten und die Zuverlässigkeit der Regelung der Systemzeit machen - also wie gut die Uhr zu "disziplinieren" ist. Dazu plottet man den Frequenz-Offset gegen die Zeit. In dem entstehenden Bild achtet man auf gleichmäßige Änderungen, es sollten kein plötzlichen oder stark abrupten Änderungen zu sehen sein. Die absolute Höhe des Offsets ist eigentlich ziemlich egal.

Schnelle Änderungen der Frequenz (ganze ppms pro Stunde) ziehen aber entsprechend große Änderungen in der Phase, also dem Offset der Zeit, nach sich. Da sollte man nach den Ursachen forschen, und oft findet man so eine defekte oder schlecht geplante Klimaanlage.

Peerstats auswerten

Die peerstats-Anweisung erzeugt eine regelmäßige Ausgabe der Werte, die aus den Paketen von den Servern kommen. Diese Werte haben zu diesem Zeitpunkt die Gesundheits-Checks überstanden und werden, je nach Ergebnis, für die weitere Berechnung verwendet.

 

52551 33870.822 192.53.103.103 9624 0.000087 0.01563 0.00021 
52551 33998.823 192.53.103.103 9624 0.000030 0.01486 0.00014 
52551 34126.824 192.53.103.103 9624 0.000047 0.01544 0.00008 
52551 34254.825 192.53.103.103 9624 0.000123 0.01544 0.00011 
52551 34372.825 192.53.103.103 9624 0.000118 0.01538 0.00006 

Die einzelnen Spalten haben folgende Bewandnis:

Debugging

Ich kann leider nur zu AIX eigene Erfahrungen beisteuern ... Wobei viele Fehler wenig vom OS abhängen.

Debugging typischer Probleme unter AIX

Zeittelegramm einer Hopf-Uhr

So zerlege ich das Zeit-Telegramm der Uhr. Das Format kommt aus der Dokumentation der Uhr.

ohager@dev:/home/ohager/Ntp-prob > cat /dev/refclock-1
CD102647100103
CD102648100103
CD102649100103
CD102650100103
CD102651100103

ohager@dev:/home/ohager > bc
obase=2
ibase=16
CD102650100103
11001101000100000010011001010000000100000000000100000011

====
Status Nibble
1100 ==>  Funkbetrieb, Hohe Genauigkeit, Winterzeit, keine Ankuendigung
01   ==>  Quartzbetrieb
00   ==>  Datum/Uhrzeit ungueltig

====
Wochentag Nibble
1101 ==>  UTC, Freitag (101)
0101 ==>  MEZ/MESZ, Freitag

Kein Hexenwerk....


[ Main | Local ]

[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | SMTP | Tracing | GPS ]

Copyright 2001-2014 by Orm Hager - Es gilt die GPL
Feedback bitte an: Orm Hager (orm@doc-tcpip.org )