| orm@doc-tcpip.org | Erstellt: Mai 2001 - Letzte Modifikation: November 2002 |
Zum Debuggen von xntpd-Problemen nutzt man am Besten das Kommando xntpdc. Es bietet eine enorme Menge an Information, von der viel auch unbrauchbar ist..
Es benutzt NTP private mode 7 Pakete für die Abfragen des NTP-Servers, was teilweise mit älteren Servern zu Problemen führt. Ein anderes, genauso geeignetes Tool (nicht so aufgeblasen..) ist ntpq. Von der Technik her sind beide Programme stark unterschiedlich, ntpq nutzt NTP mode 6 Pakete zur Kommunikation.
Ich benutzte immer xntpdc, und zwar aus folgendem Grund: xntpd verlangt alle Zeitangaben in Sekunden, und xntpdc gibt alles in Sekunden aus. Das hängt mit der Architektur dieser Programme zusammen. Das ntpq-Programm gibt aber alle Zeiten in Millisekunden zurück, und oft vergisst man, das anzupassen und hat dann den Ärger (weil heute 90% der Leute eh xntpd einsetzen). Daher den Weg des geringsten Widerstandes, auch wenn ntpq leichter zu handhaben ist.
Das xntpdc-Kommando kann man interaktiv oder mit Rückgabe einsetzen. Hier ein paar Standardbefehle für die Kommandozeile:
listpeers: Zeigt alle bekannten Peers.
memstat: Zeigt Memory-Usage des NTP Deamons.
iostat: Zeigt die (Netzwerk) I/O Charakteristik des NTP-Deamons.
loopinfo: Zeigt Werte der Schleife, die die Systemzeit regelt.
clockstat clock-adresse: Zeigt Werte der angeschloßenen Uhr.
reslist: Zeigt die für Peers definierten Restriktionen für diesen Deamon.
clkbug: Zeigt Debugging Info der Uhr.
leapinfo: Zeigt Informationen über die Sprungsekunden.
Es gibt dann noch eine ganze Reihe Befehle, um Werte zur Laufzeit zu setzen. Das steht aber alles in der man-Page.
Hier ein Beispiel mit drei Maschinen: Nimmaster nutzt seine eigene Systemzeit als Referenzuhr und ist der Master-Server. Cristina ist Client von Nimmaster, operiert im "symetric passive mode" und sendet ihrerseits Broadcasts, die von Pinocchio genutzt werden. Pinocchio ist ein Broadcastclient im "broadcast mode".
Hier wird xntpdc nach den peers, also den Partnern, des lokalen Rechners (Cristina) befragt:
root@cristina#xntpdc xntpdc> peer remote local st poll reach delay offset disp ======================================================================= ^NTP.MCAST.NET 0.0.0.5 16 64 0 0.00000 0.000000 16.0000 *nimmaster 9.39.0.74 1 512 377 0.01068 -0.000901 0.00345 xntpdc> quit root@cristina#
Es sind alle möglichen Angaben erläutert - da meine Testumgebung sehr einfach ist, kommt nur ein kleiner Teil in der Ausgabe vor.
Das * zeigt den Rechner, mit dem man gerade syncron geht.
"Synchronisieren" bedeutet, daß man die Uhr auf Cristina dazu bringt,
sich möglichst nah an das Zeitnormal anzunähern. Das Zeitnormal ist dabei
die Zeit, die in den Paketen von Nimmaster, der anerkannten Referenz angegeben
wird. Es ist nicht so, das die Uhren von Nimmaster und Cristina
gegeneinander abgeglichen werden - das ist nur ein Nebeneffekt der
gemeinsamen Annäherung an UTC bzw. das Zeitnormal. Dabei findet der
xntpd heraus, wie "falsch" die eigene Systemzeit gegenüber dem Zeitnormal
der Referenz läuft und führt die Systemzeit entsprechend nach.
Cristina sendet auf der Broadcast-Adresse für NTP als Server
(NTP.MCAST.NET und 0.0.0.5).
Ein - heisst, dass dieser Peer "symmetrisch passive"
operiert.
Dieser Server wird von Clients regelmäßig "gepollt", also die
Clients
fragen in einem bestimmten, eigenen Rythmus nach der Zeit. Die Clients müßen im
"symmetrisch aktiven" Mode sein. Ein Server in diesem Mode kann den Client
auch selbst pollen.
Ein + heisst, dass dieser Peer "symmetrisch active"
operiert.
Der Host fragt einen Server nach der Zeit und synchronisiert sich mit ihm.
Der Server kann diesen Host auch um die Zeit bitten.
Ein = heisst, das der remote Server im client mode
gepollt wird.
Der Host sendet also Anfragen, NTP-Pakete, zu diesem Server, er "pollt" ihn.
Seinerseits antwortet er nicht auf Anfragen. Der Server operiert im
server mode
Das ~ heisst, das der remote Server Broadcasts schickt.
Das st ist das Stratum.
Nimmaster hat Stratum 1, da es die Quelle aller
Zeit in diesem Netz ist. Die Broadcast-Clients werden als
unsyncronisiert angesehen, daher das Stratum 16 (die Verbindung ist nicht
symmetrisch).
Der Begriff des Stratums ist eigentlich eine topologische Größe. Ein Server
mit Zugang zu einer guten Zeitquelle ist die erste Ebene, und danach
wird einfach
pro Hop abwärts gezählt. Dabei gilt, das ein Host sich nur mit Maschinen
auf einem niedrigeren Stratum (oder mit dem gleichen Stratum) synchronisiert.
Das poll ist die Zeit in Sekunden zwischen den Anfragen bzw. gesendeten Paketen.
Das reach ist das reachability register in Oktal.
Die Synchronisation erfolgt durch Auswerten der erhaltenen Zeitinformation.
Der Deamon ermittelt statistische Werte für jede Messung. Dazu
werden 8 Messungen benutzt. Jedes Paket wird einer Serie von Prüfungen
unterzogen, und in diesem Register kann man das sehen. Das Register hat
8 Bit. Für jedes akzeptierte Paket wird das niedrigste Bit auf 1 gesetzt
und das Register nach links verschoben, das höchste Bit fällt sozusagen
raus. Man kann jetzt lernen, wie man Oktale Zahlen liest, oder den bc
bemühen (obase=2 sagt, das er die Zahl Binär ausgeben soll, ibase=8
sagt, das wir Oktal mit ihm reden):
doctcp@elbueno:~/www/doctcp > bc obase=2 ibase=8 377 11111111 257 10101111 357 11101111Also: 377 bedeutet, wir haben die letzten 8 Pakete gut empfangen, 257 bedeutet, das uns die Pakete 2 und 4 verloren gegangen sind, und 357 zeigt Paket 4 als verloren an - immer bezogen auf die 8 letzten Pakete.
Das delay gibt die Rundlauf-Zeit im Netz an.
Das offset zeigt das Verhältnis der Systemzeit des Clients
zur mitgeteilten Referenzzeit an.
Überschreitet der Offset eine gewisse Grenze, so wird die clientseitige
Systemzeit nachgeführt. Das kann auf zwei verschiedene Weisen (abhängig
von der Differenz) erfolgen: stepping ändert die Zeit in Sprüngen,
während slewing die Zeit in kleinen Schritten nachgeführt wird.
Die disp ist die Dispersion, also der geschätzte, maximal Fehler des
aufgrund der letzten gültigen mindestens 5 Proben (Pakete/Messungen)
ermittelte Offset.
Wird in Sekunden angegeben und gibt ein Maß für den Delay plus aller
Fehler. Die Anpassung der lokalen Uhr wird im Bereich Dispersion -
Offset bis Dispersion + Offset liegen.
Die Präzision eines Hosts ist dabei: Delay * Alter der Referenzzeit /
86400.
Für die Statistik werden die Zeitinformationen aller Peers berücksichtigt, die entweder mit einem "*" oder einem "+" gekennzeichnet sind.
Aus dem Ergebnis der Berechnungen werden zwei Werte abgeleitet: drift und skew. Diese Werte werden in ein File geschrieben, sodaß die Systemzeit nicht bei jedem Boot neu synchronisiert werden muß.
Der skew ist ein Wert in Hertz pro Sekunde, der dem Frequenzunterschied zwischen der Anzahl an Schwingungen, die der Client für eine Sekunde hält und der Anzahl an "Ticks" die laut der Auswertung der Zeitinformation wirklich einer Sekunde entsprechen (Also: ich sage, das 500 Schwingungen meines Kristalles eine Sekunde sind. Die Auswertung der Zeitinformation belehrt mich, das ich immer 11 Schwingungen, also Hz, zu schnell bin. Ich brauche also wirklich nur 489 Schwingungen und kann nun meine Uhr regelmäßig nachführen). Im Idealfall hängt dieser Wert nur von der Hardware ab und sollte, einmal ermittelt, konstant bleiben.
Die drift ist auch ein Wert in Hertz pro Sekunde, der aber eine Aussage
macht, wie stark sich der skew ändert. Im Zuge einer Synchronisation
sollte der drift-Wert sich einem Minimum nähern. Was durch Wärme
etc. verursacht wird.
Konzentrieren wir uns auf den Cristinas Synchronisation an Nimmasters
Referenzzeit
betreffenden Teil der Ausgabe von xntpdc:
remote local st poll reach delay offset disp ======================================================================= *nimmaster 9.39.0.74 1 512 377 0.01068 -0.000901 0.00345
Die Ausgabe zeigt, das eine Anfrage von Cristina an Nimmaster 1068 Millisekunden braucht, die Systemzeit auf Cristina 901 Mikrosekunden hinter der Referenz herläuft, und das die durchschnittliche Abweichung 3450 Mikrosekunden beträgt. Die 8 Pakete/Proben, auf denen diese Statistik basiert, wurden komplett und in Reihenfolge empfangen. Für Cristina ist Nimmaster ein Rechner des Stratum 1, er hat also direkten Zugang zu einer sehr zuverlässigen Zeitquelle. Cristina fragt alle 512 Sekunden nach einem Update (der "poll intervall" ist also 512 Sekunden). Im grossen und Ganzen sind diese Werte sehr gut, die Abweichung ist relativ gering, und die Schwankung der Proben auch. Das System hat sich schon auf einen großen Intervall eingependelt (die Drift der Zeit ist also gering).
Wie sieht das jetzt auf dem Client von Cristina aus? Schließlich ist Cristina nicht nur Client von Nimmaster, sondern auch Broadcast-Server in ihrem lokalen Netz. Hier also die Ausgabe von Pinocchio:
root@pinocchio#xntpdc xntpdc> peer remote local st poll reach delay offset disp ======================================================================= *cristina.ncs.ma 0.0.0.0 2 64 377 0.00157 0.000061 0.00108 root@pinocchio#
Pinocchio ist ein Broadcastclient.
Der Delay ist deutlich geringer - logisch, da es sich hier um UDP-Broadcasts handelt, Pinocchio also keine Anfragen stellt, sondern regelmäßig einen Update gesendet bekommt (alle 64 Sekunden). Daher ist auch die Dispersion geringer. Allerdings sind Cristina und Pinocchio Maschinen gleichen Typs, während Nimmaster eine sehr alte IBM Microchannel Maschine ist. Pinocchio sieht Cristina im Stratum 2. Will man den Offset zwischen Pinocchio und der Referenz ermitteln, so muß man den Offset von Cristina dabei berücksichtigen - was auch für Dispersion und Delay gilt, also auch für die Host-Präzision.
Jetzt fehlt noch die Ausgabe auf dem eigentlichen Zeit-Server, Nimmaster. Dieser synchronisiert gegen seine "Local Clock", also die in der Maschine eingebaute Uhr. Das ist ntürlich nicht sonderlich schlau, an dieser Stelle sollte man gegen eine Funkuhr oder gegen Zeitserver im Internet synchronisieren.
root@nimmaster#xntpdc xntpdc> peer remote local st poll reach delay offset disp ======================================================================= *LOCAL(0) 127.0.0.1 0 64 377 0.00000 0.000000 0.01003 root@nimmaster#
Mein Deamon fragt also alle 64 Sekunden die Systemuhr ab, alle Anfragen kommen an, es gibt kein Delay und auch keinen Offset. Allerdings gibt es nicht unerhebliche Schwankungen - offensichtlich ist die Uhr nicht so stabil, wie man erwartet.
Es ist möglich, eine Unmenge an Information aus dem Prozess zu erhalten. Teilweise ist diese Information aber nur für einen Programierer interessant...
Weiterhin ändern sich die Schalter ab und an, und auch die Ausgabe kann je nach Version unterschiedlich sein. Mit xntpdc> help kann man die Möglichkeiten entdecken. Im folgenden Beipiele und Erklärungen einiger xntpdc-Subkommandos:
sysinfo
xntpdc> sysinfo system peer: GENERIC(1) system peer mode: client leap indicator: 00 stratum: 1 precision: -15 root distance: 0.00000 s root dispersion: 0.00615 s reference ID: [DCF] reference time: c170bc50.00000000 Mon, Nov 4 2002 10:28:48.000 system flags: auth monitor pll stats frequency: 16.000 ppm stability: 17.382 ppm broadcastdelay: 0.003906 s authdelay: 0.000122 s
memstat
Gibt Information über die Nutzung des Memory, das der NTP Deamon
nutzt. Pro Peer gibt es einen Eintrag, der dann auch in der Hash-Table
auftaucht. Hier ziemlich langweilig, weil nur ein Peer vorhanden ist -
die Uhr.
xntpdc> memstat
time since reset: 1095043
total peer memory: 15
free peer memory: 14
calls to findpeer: 126726
new peer allocations: 0
peer demobilizations: 0
hash table counts: 0 0 0 0 0 0 0 0
0 1 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
iostat
Dieser Schalter wird interesant, wenn man einen Deamon mit vielen
Peers betreibt, oder einen Server. Die Statistiken beschreiben
wie der Deamon mit den Anfragen und Zeitinformationen (das ist
immer ein Austausch von einzelnen Paketen) umgeht. Außerdem
gibt es noch ein wenig Information über Speicher-Probleme.
Hier handelt es sich um einen Server mit einer Uhr. Daher ist die Anzahl der empfangenen Pakete deutlich höher als die der gesendeten (es ist sinnlos, Pakete an die Uhr zu schicken..).
xntpdc> iostat time since reset: 362897 receive buffers: 10 free receive buffers: 9 used receive buffers: 0 low water refills: 0 dropped packets: 0 ignored packets: 0 received packets: 1139436 packets sent: 52549 packets not sent: 0 interrupts handled: 2228001 received by int: 1139351
received packets: 17192 packets sent: 17199 packets not sent: 0 interrupts handled: 17192 received by interrupt: 17192
loopinfo
Gibt Informationen über die Schleife, die zur Disziplinierung der
Systemzeit durch den NTP Deamon benutzt wird. Es wird der effektive
Zeit-Offset in Sekunden angegeben, der Frequent-Offset in Sekunden
oder (je nach Version) in ppm. Die Angabe compliance/poll adjust
ist der Wert, um den die Häufigkeit der Anfragen an den Server geändert
wird. Wirklich modifiziert wird das aber nur, wenn der neue Wert mit
log2 darstellbar ist (64, 128, 256 ...). Der Timer ist zeigt die Zeit
bis zur nächsten Anfrage.
xntpdc> loopinfo offset: 0.0014935 seconds frequency: 14.7121429 seconds compliance: 3 seconds timer: 74 seconds xntpdc> loopinfo offset: -0.003713 s frequency: 995.712 ppm poll adjust: -30 watchdog timer: 47 s
clockstat
Dieser Befehl ist sehr nützlich, wenn man ein Problem mit der
angeschloßenen Uhr vermutet. Besonders DCF77-Uhren haben gerne
Probleme mit der Antenne bzw. dem Empfang. Interessant ist daher
die abgelaufene Zeit (running time), die Anzahl der Anfragen (polls)
und die Angaben für "keine Antwort", "falsches Format" und "ungültige
Daten". Weiterhin kann man so die für die Uhr eingestellten Korrekturen
(Fudge) prüfen.
xntpdc> clockstat 127.127.8.1 clock address: 127.127.8.1 clock type: Generic reference clock driver (8) last event: 2 current status: 0 number of polls: 5672 no response to poll: 7 bad format responses: 4 bad data responses: 0 running time: 362961 fudge time 1: 0.000000 fudge time 2: 0.000000 stratum: 0 reference ID: DCF fudge flags: 0x0
showpeer
Zeigt Einstellungen und statistische Werte zu einem bestimmten Peer.
Hier im Beispiel sind zwei verschiedene Versionen Abfragen einer
angeschloßenen DCF-Uhr zu sehen. In so einem Fall ist die Rootdistance
und -Dispersion natürlich 0, weil die Uhr ja selbst Root ist. Die
Angaben zum Filter kann ich nicht interpretieren, die meisten Angaben
und Flags sind wie in den anderen Kommandos. Interessant sind die
Zeitstempel sowie die errechneten Delays, Offset und Dispersion.
Man erhält so ein Bild des Peers, über längeren Zeitraum eine Angabe
zur Präzision und Stabilität des Peers.
xntpdc> showpeer 127.127.8.1
remote 127.127.8.1, local 127.0.0.1
hmode client, pmode mode#255, stratum 0, precision -16
leap 00, refid [DCF], rootdistance 0.0000, rootdispersion 0.0000
ppoll 6, hpoll 6, keyid 0, version 3, association 15252
valid 8, reach 377, unreach 0, trust 000
timer 50s, flags system_peer, configured, reference_clock
reference time: c170b906.00000000 Mon, Nov 4 2002 10:14:46.000
originate timestamp: c170b906.00000000 Mon, Nov 4 2002 10:14:46.000
receive timestamp: c170b906.00000000 Mon, Nov 4 2002 10:14:46.000
transmit timestamp: c170b905.b47a3000 Mon, Nov 4 2002 10:14:45.704
filter delay: 0.0000 0.0000 0.0000 0.0000
0.0000 0.0000 0.0000 0.0000
filter offset: -0.01172 0.00519 0.00211 -0.00546
-0.01075 0.00971 0.00334 -0.00165
filter order: 0 1 2 3
4 5 6 7
bdelay filter: 0.00000 0.00000 0.00000 0.00000
0.00000 0.00000 0.00000 0.00000
delay 0.0000, estbdelay 0.0000
offset -0.011720, dispersion 0.0159
xntpdc> showpeer 127.127.8.1
remote 127.127.8.1, local 127.0.0.1
hmode client, pmode unspec, stratum 0, precision -15
leap 00, refid [DCF], rootdistance 0.00000, rootdispersion 0.00000
ppoll 6, hpoll 6, keyid 0, version 3, association 12420
valid 8, reach 377, unreach 0, flash 000, boffset 0.00391, ttl/mode 12
timer 31s, flags system_peer, config, refclock, bclient
reference time: c170bcd0.00000000 Mon, Nov 4 2002 10:30:56.000
originate timestamp: c170bcd0.00000000 Mon, Nov 4 2002 10:30:56.000
receive timestamp: c170bcd0.00000000 Mon, Nov 4 2002 10:30:56.000
transmit timestamp: c170bccf.c99f3000 Mon, Nov 4 2002 10:30:55.787
filter delay: 0.00000 0.00000 0.00000 0.00000
0.00000 0.00000 0.00000 0.00000
filter offset: -0.00278 -0.00371 -0.00437 -0.00541
-0.00625 -0.00718 -0.00818 -0.00921
filter order: 0 1 2 3
4 5 6 7
offset -0.002785, delay 0.00000, dispersion 0.00174, selectdisp 0.00000
pstats
Gibt Informationen wie ein Peer den Selektions-Algorithmus
überlebt und weshalb er einen bestimmten Rang in der Kandidaten-Reihe
bekommt. Hier zwei Beispiele, einmal die angeschloßene Uhr und dann
ein richtiger Server:
xntpdc> pstats 127.127.8.1 remote host: GENERIC(1) local interface: 127.0.0.1 time last received: 6s time until next send: 58s reachability change: 1095623s packets sent: 17120 packets received: 0 packets processed: 17120 bad length packets: 0 bad auth packets: 0 bogus origin packets: 0 duplicate packets: 0 bad delay rejections: 0 select delay rejects: -1049577210 select disp rejects: 8 select finds broken: 0 too old for select: 0 sel candidate order: 1 falseticker order: 112 select order: 185 select total: 5 xntpdc> pstats 10.10.10.1 remote host: speedy.ls.net local interface: 10.10.10.12 time last received: 71s time until next send: 57s reachability change: 484354s packets sent: 17194 packets received: 0 packets processed: 17186 bad length packets: 0 bad auth packets: 0 bogus origin packets: 3 duplicate packets: 0 bad delay rejections: 0 select delay rejects: 0 select disp rejects: 0 select finds broken: 0 too old for select: 34 sel candidate order: 1 falseticker order: 0 select order: 1 select total: 0
listpeers
Zeigt alle dem NTP Deamon bekannten Peers. Hier nur die angeschloßene
Uhr.
xntpdc> listpeers client GENERIC(1)
reslist
Zeigt die für verschiedene Peers definierten Restriktionen, also ob
Authentifizierung oder Ähnliches definiert ist. Außerdem kann man
hier Maschinen, denen man nicht traut, ausschließen.
xntpdc> reslist address mask count flags ===================================================================== 0.0.0.0 0.0.0.0 143929 none 10.10.10.1 255.255.255.255 0 ntpport, interface, ignore 127.0.0.1 255.255.255.255 0 ntpport, interface, ignore 193.158.128.76 255.255.255.255 0 ntpport, interface, ignore
clkbug
Die Ausgabe kann ich nicht interpretieren, sieht aber interessant
aus. Man erkennt den Zeitstempel, und wohl eine Reihe Werte für
Offset und wahrscheinlich den Fehler.
xntpdc> clkbug 127.127.8.1
clock address: 127.127.8.1
values: 8
0 0 0 0
0 0 0 1095758
times: 8
3245390214.000000 02:307:09:16:54.0003245390214.000000
02:307:09:16:54.000
0.001602 0.012451
0.011687 0.010783
0.014213 0.013292
leapinfo
Zeigt alles, was man über die anstehenden Sprungsekunden, die die
Systemzeit auf UTC bringen, wissen muß. Es ist nicht vorhersehbar,
wann eine Sprung-Sekunde angeordnet wird. Meist ist das jedoch im
August und im Dezember (das hat wohl was mit Astronomie zu tun).
Daher wird jeden Tag gecheckt, ob sich was geändert hat und
das Register neu gesetzt. Das ist hier 14 mal gemacht worden,
und 14 mal war die Antwort, das ein Sprung mehr als 1 Monat in
der Zukunft liegt. Das wird dann kürzer, und irgendwann passiert
es. Die Zeile "leap happend" sieht man selten höher als 1, in
der Regel bootet man öfter.
xntpdc> leapinfo sys.leap: 00 (no leap second scheduled) leap.indicator: 00 (leap controlled by lower stratum) leap.warning: 00 (leap controlled by lower stratum) leap.bits: 00 (no leap second scheduled) time to next leap interrupt: 27467 seconds date of next leap interrupt: Mon, Nov 4 2002 18:00:16 calls to leap process: 14 leap more than month away: 14 leap less than month away: 0 leap less than day away: 0 leap in less than 2 hours: 0 leap happened: 0
Weitere Schalter
Es gibt noch eine Reihe weiterer Befehle, auf die nicht eingegangen
wird. Diese dienen zum Resetten von Zählern, oder zum definieren
von Peers, Flags etc. Außerdem kann man verschiedene Dinge mit
der "monitor" Anweisung mitschreiben und mit "monlist" auslesen.
[ 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