| orm@doc-tcpip.org | Erstellt: Juni 2001 - Letzte Modifikation: November 2002 |
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.
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...
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.
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:
Die ersten beiden Spalten geben den Zeitpunkt an, als diese Werte angewendet wurden. Es sind der modifizierte Julianische Tag und die Sekunden seit 00:00 UTC. In diesem Fall ergibt das (nach der Umrechungstabelle) den 4. Oktober 2002. Die Werte wurden ab 10:24 CET/MEZ registriert.
Die dritte Spalte ist jetzt der Offset in Sekunden, um den in dieser Schleife die Uhr nachgestellt werden wird.
Die vierte Spalte ist der geschätzte Frequenz-Offset in ppm, Parts per Million. Das ist oben schonmal berechnet worden, im Beispiel kämen wir auf 6.2528 ppm => 6.2528 10^-6 * 3600 * 24 = 0.540 Sekunden/Tag.
Die fünfte Spalte ist der Logarithmus zur Basis 2 des Polling Intervals, also wie oft der Client beim Server anfragt. Das ist abhängig von der Qualität der Syncronisaton, wenn alles gut läuft, wird der Interval bis auf "maxpoll" steigen. Im Beispiel heißt die 7 also 2e7 = 128 Sekunden, und die 8 bedeutet alle 256 Sekunden eine Anfrage an den Server.
Bei Version NTP 4 würden zwischen den Spalten 4 und 5 noch zwei weitere Spalten mit dem Mittleren Fehler in Sekunden und der Allan Deviation in ppm auftauchen.
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.
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:
Die ersten beiden Spalten geben den Zeitpunkt an, als diese Werte ermittelt wurden. Es sind der modifizierte Julianische Tag und die Sekunden seit 00:00 UTC. In diesem Fall ergibt das (nach der Umrechungstabelle) den 4. Oktober 2002. Die Werte wurden ab 10:24 CET/MEZ registriert.
Die dritte Spalte ist die IP Adresse der Servers, der diese Zeitinformation gesendet hat.
Die vierte Spalte ist ein Status Register, das den Zustand des sendenten Servers zeigt. Das Register besteht aus 4 Hex-Werten, wobei die ersten beiden Werte die Server-Konfiguration und einen Status über das Abschneiden bei der Server Auswahl geben. Die beiden anderen Hex-Werte setzt der Client, sie zeigen an, wie er mit dem Server kommunizieren kann.
Erster Hex-Wert:
1 = Dieser Server wollte mit
diesem Client eine Peer-Verbindung aufnehmen, ist aber
nicht konfiguriert.
7 = Dieser Server ist zwar als
Peer nicht konfiguriert, konnte sich aber authentifizieren
(seine Zeit-Information wird beachtet).
8 = Der Server
ist als Peer konfiguriert, aber nicht zu erreichen oder
kann sich nicht authentifizieren.
9 = Der Server
ist konfiguriert und erreichbar.
C = Der Server
ist konfiguriert, aber nicht erreichbar.
D = Der
Server ist konfiguriert und erreichbar, nutzt aber keinen
Trusted Key.
F = Der Server ist authentifiziert und
erreichbar.
Zweiter Hex-Wert:
0 =
Der Server ist nicht durch die Gesundheits-Checks gekommen
und wird nicht beachtet.
1 = Der Server ist durch
die Gesundheits-Checks gekommen, aber zuweit von den
anderen Servern weg.
2 = Der Server ist durch die
Gesundheits-Checks gekommen und auf Korrektheit geprüft
(gegen seine letzten Pakete).
3 = Der Server ist
durch die Kandidaten Prüfung durch und somit in der
10er Gruppe.
4 = Der Server ist beim Clustering
nicht mit zu hoher Dispersion aufgefallen.
5 =
Der Server wäre eigentlich Syncronisatons-Partner,
ist aber zu weit ab (gegen die letzten Pakete). Das
ist Schlimm, entweder sind alle weit ab, oder alle
anderen sind krank.
6 = Der Server ist der aktuelle
Syncronisatons-Partner.
7-F = Reserviert.
Dritter Hex-Wert:
Zählt die Events/Fehler
hoch, seit dem letzten Zeitpunkt, das Jemand mit ntpq das
Register abgefragt hat. Sollte 0 oder 1 sein, ist der
Wert höher, dann ist etwas passiert. Was, das verrät der
vierte Wert.
Vierter Hex-Wert:
0 =
Ein nicht weiter definierter Event/Error.
1 = Ein IP
Fehler, beim Versuch, den Server zu kontaktieren.
2 = Ein bisher funktionierender Server kann sich nicht
mehr authentifizieren.
3 = Ein Server ist plötzlich
nicht mehr erreichbar.
4 = Ein unerreichbarer
Server ist wieder da.
5 = Die Server-Uhr hatte einen
Fehler.
6-F = Reserviert.
Die fünfte Spalte zeigt den geschätzten Offset in Sekunden. Das ist der Zeitunterschied zwischen Server und Client.
Die sechste Spalte zeigt die Rundlaufzeit in Sekunden, also die Netz-Verzögerung, die zwischen Server und Client auftritt.
Die siebte Spalte zeigt die Dispersion in Sekunden, also den maximal möglichen Fehler des Offset. Ist der Client also im Gleichgewicht und ist die Zeit des Servers gut, dann liegt die Abweichung des Clients von UTC im Bereich Offset - Dispersion und Offset + Dispersion. Das zeigt schnell die Genauigkeit des Clients.
Im Fall der NTP Version 4 steht im achten Feld die Varianz der Dispersion (skew).
Ich kann leider nur zu AIX eigene Erfahrungen beisteuern ... Wobei viele Fehler wenig vom OS abhängen.
Multicast-Probleme
- Horcht der Adapter wirklich auf der Multicast
Adresse?
Hat man einen Client mit folgendem Eintrag
im ntp.conf:
multicastclient driftfile /... tracefile /...Dann sollte man mit dem Kommando netstat -ain die Multicastadresse 224.0.1.1 sehen können. Diese wird beim Start des xntpd automatisch eingerichtet. Die Server-Konfiguration ist dann in dieser Art:
server 127.127.1.0 prefer fudge 127.127.1.0 stratum 0 driftfile /... tracefile /... broadcast 224.0.1.1Es ist natürlich ziemlich Dumm, die Zeit der Local Clock zu verteilen...
Der xntpd kommt hoch,
stirbt aber sofort - Das kann daran liegen, das
die Kernel-Extension für den tickadj() Systemcall
nicht richtig initialisiert ist:
Zuerst gleicht
man mit dem Kommando ntpdate die Zeit manual an
und prüft die Zeitzonen-Variable $TZ. Ein rascher
Blick auf den Link zum Kernel-Image (im Root-Verzeichnis,
/usr/lib/boot/unix-up) spart eventuell viel Arbeit..
Man fährt den xntpd hoch (/usr/sbin/xntpd)
und setzt dann echo $? ab. Es sollte 0, also kein
Problem zurückkommen. Danach startet man den xntpd
im Debug-Modus: /usr/sbin/xntpd -d -d -d -d -d
und schaut dann ins syslog. Finden sich solche
Nachrichten: xntpd[16896]: tickadj or tick
unknown, exiting. gibt es ein Problem mit
der Kernel-Extention. Mit dem crash-Kommando kann
man sich das näher ansehen. Dazu ruft man crash
auf, setzt am Prompt nm -x tickadj auf, merkt
sich die Hexnumber und führt, immer noch in Crash,
od 0xhexnumber aus. Das sollte einen Wert von
Hex 3e8 (Dez. 1000) ergeben. Weicht der Wert ab, hilft
in der Regel ein Reboot.
Der
xntpd kommt hoch, stirbt aber nach etwa 15 -
20 Minuten wieder - Mit ziemlicher Sicherheit
ist die Zeit des Clients weit von der Zeit des Servers
entfernt. Mehr als etwa 1000 Sekunden quitiert der xntpd
mit Ausstieg. Liegt die Differenz in dieser Größenordnung,
dann wartet der xntpd eine ganze Zeit ab, er will sicher
sein, das es kein sporadischer Fehler ist. Erst danach
steigt er aus. Daher dieser magische Zeitraum.
Übel ist es auch, wenn die Deamons auf Client und Server
mit unterschiedlichen Zeitzonen gestartet wurden. Dann
sieht die Zeit gleich aus, ist es aber nicht. Das muß
man in den Locales richten und dann rebooten...
Vor dem Neustart des xntpd sollte man dann die Zeit
mit dem date-Kommando, oder etwas eleganter mit
dem ntpdate-Kommando angleichen.
Adress already in use-Fehler - Das ist besonders ärgerlich, da es nicht nur simpel daran liegen muß, das ein anderer Deamon sich den Port geschnappt hat. Unter AIX kann das passieren (man startet den xntpd über den SRC: startsrc -s xntpd -a "-d -d -d -d -d" und schaut dann ins Syslog):
bind() fd10,family2,port123,addr34.., in_class d=0 flags=0 fails: Adress already in use.Es kann auch daran liegen, das die Maschine 2 Interfaces imselben Subnetz hat - also zwei identische Broadcastadressen. Startet man nun den xntpd über den SRC als broadcastclient, dann weiß er nicht, an welche Adresse er binden soll und steigt aus. Man kann ihn entweder von Hand starten, oder im server-Mode betreiben. Eine große Überraschung ist, das es funktioniert, wenn man den Deamon von Hand startet...
Pakete tracen
mit tcpdump - Das ist einfach:
tcpdump -I -i en0 -vvn -s 100 port 123 & *
Für Interface en0
tcpdump -I -i tr0 -vvn -s 100
port 123 & * Für Interface tr0
Weiterhin kann
man das Keywort tracelevel im
Konfiguratiosnfile /etc/ntp.conf angeben. Man
muß einen Level spezifizieren, 4 ist brauchbar
(tracelevel 4).
Meine DCF77 Funkuhr geht nicht - Das kommt vor... Der xntpd, der von der IBM in AIX implementiert wird, ist nicht der "original" xntpd. Eine ganze Reihe von Treibern für verschiedene Uhren-Modelle fehlen. Es entsteht dann die nette Situation, das die Uhr mit der AIX-Version des Deamons nicht geht, mit der offiziellen xntpd-Version jedoch sehr wohl. Das wäre schön und gut, wenn der offizielle Deamon nicht einen kleinen Schönheitsfehler hätte: Er harmoniert nicht mit dem SRC (System Resource Controler), man muß ihn also in eingenen Skripten aus der /etc/inittab oder z.B. aus /etc/rc.local starten. Ob die entsprechende Uhr vom Deamon unterstützt wird, kann man mit dem Kommando strings xntpd herausfinden. Man erhält eine Liste aller Fabrikate, für die Treiber existieren. Jedenfalls sollte man den AIX-Support und den Vertriebspartner bemühen und ein DCR (Design Change Request) durchführen. DCF77 Uhren werden meinem Eindruck nach etwas stiefmütterlich behandelt.
Wo kriege ich eine Funkuhr her? - Uhren
in Industriestandard aus heimischer Produktion (yeah):
www.meinberg.de
www.hopf-time.com
Beide Hersteller bieten DCF77 Zeitempfänger verschiedenster
Typen an.
Wenn ich die Uhr habe,
was mache ich dann? - Eigentlich simpel: die
Uhr kommt an einen seriellen Port, es wird ein Link vom
entsprechenden tty zu /dev/refclock erzeugt und
schon sollte es losgehen. Dann kann man den xntpd
starten.
Ein Beispiel: Eine Hopf DCF77 an Port
s2.
Im /etc/ntp.conf steht folgendes:
server 127.127.8.1 mode 12 fudge 127.127.8.1 stratum 0 refid hopfDas tty muß man natürlich entsprechend definiert haben. Es sollte clocal und hupcl eingestellt haben. Dann wird ein Link von /dev/tty0 nach /dev/refclock-0 eingerichtet:
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....
[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]
Copyright 2001-2021 by Orm Hager - Es gilt die GPL