orm@doc-tcpip.org

Erstellt: Mai 2001 - Letzte Modifikation: November 2002

[ Main | Local ]


Das xntpdc-Kommando

Beispiele aus dem richtigen Leben

Praktische Beispiele zum xntpd-Kommando

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:


Interaktive Kommandos(nicht alle):

Es gibt dann noch eine ganze Reihe Befehle, um Werte zur Laufzeit zu setzen. Das steht aber alles in der man-Page.

Das ganze am Beispiel:

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.

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.

Das xntpdc Tool kann noch mehr

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:


[ 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 )