Das Network Time Protocol (NTP)

Das freie Software-Paket NTP (Network Time Protocol) ist eine Implementierung des gleichnamigen TCP/IP-Protokolls zur Zeitsynchronisierung von Geräten im Netzwerk.

NTP wurde in den 1980er Jahren von Dave L. Mills in den USA entwickelt, der versuchte, die Systemzeiten mehrer Rechner im Netzwerk mit möglichst hoher Genauigkeit zu synchronisieren. Das zugrundeliegende Netzwerkprotokoll und die verwendeten Algorithmen wurden in mehreren RFCs veröffentlicht.

Seit der Einführung des Protokolls wurde NTP kontinuierlich verbessert und erweitert. Heute ist NTP weltweit das Standard-Protokoll zur Zeitsynchronisierung über das Netzwerk. Das Protokoll selbst unterstützt eine Zeitgenauigkeit bis in den Nanosekundenbereich hinein. Die tatsächlich erreichbare Genauigkeit hängt jedoch in großem Maß von den verwendeten Betriebssystemen und der Qualität der Netzwerkverbindungen ab.

Momentan exististieren zwei Versionen des NTP-Protokolls, die auch miteinander verwendet werden können: NTP v3 ist die letzte Release-Version, die sehr stabil unter vielen Betriebssystemen läuft. In NTP v4 sind einige Verbesserungen vorgenommen worden. Außerden werden einige neuere Betriebssysteme besser unterstützt.

Außer der normalen Version des NTP-Protokolls gibt es auch eine vereinfachte Version namens SNTP (Simple Network Time Protocol). SNTP benutzt die gleiche Struktur für die Netzwerk-Pakete, es verwendet jedoch einfachere Algorithmen für die Zeitsynchronisierung und erreicht daher nur eine geringere Genauigkeit.

Der Hauptbestandteil eines NTP-Programmpaket ist ein Programm, das komplett im Hintergrund läuft (Daemon oder Service genannt) und die Zeit des eigenen Rechners möglichst synchron zu einer oder mehreren externen Referenzzeiten hält. Ein Referenzzeitgeber kann entweder ein anderes Gerät im Netzwerk sein oder auch eine Funkuhr, die direkt an den Computer angeschlossen ist.

Zu der Distribution gehören außerdem Kontroll- und Monitorprogramme sowie eine komplette Dokumentation im HTML-Format.

NTP wurde ursprünglich für UNIX entwickelt. Heutzutage läuft das Programm unter vielen Unix-Derivaten und Unix-ähnlichen Systemen. NTP v4 wurde sogar nach Windows portiert und läuft unter Windows NT, Windows 2000 und neueren Versionen einschließlich Windows Vista und Windows 7.

Das Standard-NTP-Paket läuft jedoch nicht unter Windows 9x/ME da diesen Betriebssystemen einige Fähigkeiten fehlen, die NTP für eine gute Zeitsynchronisierung benötigt. Für Windows 9x/ME und andere Betriebssysteme, die nicht direkt durch das Standard-Paket unterstützt werden, sind einige andere NTP- oder SNTP-Programme im Internet verfügbar.

Eine Übersicht an verfügbaren Programmen findet man auf der Support Seite der NTP-Homepage.

Heute werden bereits viele Betriebssysteme mit einem vorinstallierten NTP-Programm ausgeliefert. Aus diesem Grund bietet Meinberg unter dem Produktnamen LANTIME eine Serie von NTP-Timeservern an, die mit verschiedenen eingebauten Zeitreferenzen wie z.B. Empfängern für GPS oder DCF77 PZF. Die Geräte haben ein Netzwerkinterface sowie eine Stromversorgung eingebaut und sind sehr einfach in ein vorhandenes Netzwerk zu integrieren.

Die Standard-NTP-Distibution enthält den NTP-Daemon selbst und dazu einige Hilfsprogramme. Frühere Versionen der NTP-Distribution sowie einige in dem Paket enthaltene Programme hatten Namen, die mit xntp begannen (z.B. xntpd) während andere Programme des Pakets Namen mit ntp hatten (z.B. ntpq).

Ab NTP-Version 4 wird eine einheitlichere Namensgebung verwendet, so beginnt jetzt der Name des Paketes selbst sowie die Namen aller enthaltenen Programme mit der Zeichenfolge ntp (z.B. ntpd, ntpq).

Unter Unix-ähnlichen Systemen wird der NTP-Daemon oft beim Hochlaufen des Systems über ein Script gestartet, das manchmal immer noch einen mit xntp beginnenden Namen hat, obwohl der tatsächliche Name des Daemons ntpd ist. Dies ist zum Beispiel bei SuSE/openSUSE Linux der Fall.

Der NTP-Daemon kann nicht nur die Zeit seines eigenen Rechners synchronisieren, sondern kann auch Client, Server, oder Peer für andere NTP-Daemons im Netzwerk sein:

• Als Client holt er sich die Referenzzeit von einem oder mehreren Servern.
• Als Server stellt er seine eigene Zeit anderen NTP-Clients im Netzwerk zur Verfügung.
• Als Peer vergleicht er seine eigene Zeit mit mehreren anderen NTP-Peers, die sich schließlich auf eine gemeinsame Zeit einigen, nach der sich alle richten.

Mit Hilfe dieser Möglichkeiten kann auf einfache Weise eine hierarchische Zeitverteilung in einem Netzwerk eingerichtet werden. Die einzelnen Hierarchie-Ebenen werden stratum genannt. Eine kleinerer Stratum-Wert bedeutet dabei eine höhere Ebene in der Hierarchie-Struktur.

Jeder NTP-Daemon hat einen Stratum-Wert, der um eins höher ist als der Stratum-Wert seiner Referenzzeitquelle. Auf der obersten Hierarchie-Ebene befindet sich der NTP-Daemon mit der genauesten Zeit und dem kleinsten Stratum-Wert, der normalerweise als Referenzzeit eine Funkuhr verwendet.

Funkuhren haben normalerweise den Stratum-Wert 0. Daher wird der NTP-Daemon, der die Funkuhr direkt als Referenz benutzt, zum Stratum-1-Timeserver , der die höchste Priorität in der NTP-Hierarchie hat. In der Praxis wird man in größeren Netzwerken einen oder mehrere Stratum-1-Timeserver einrichten, die ihre Zeit den Servern in den einzelnen Abteilungen bereitstellen. Diese werden dadurch zu Stratum-2-Servern, auf die sich weitere Geräte und Arbeitsplatzrechner im Netzwerk synchronisieren können.

Im Unterschied zu Telekom-Anwendungen, wo der Begriff stratum z.B. dazu verwendet wird, Oszillatoren nach Ihrer Genauigkeit zu klassifizieren, beinhaltet der bei NTP verwendete stratum-Wert keine Angabe zur Genauigkeit der Zeitquelle, sondern gibt nur die Hierarchie-Ebene wieder.

Jeder NTP-Daemon kann so konfiguriert werden, dass zyklisch mehrere unabhängige Referenzzeitquellen abgefragt werden. Die einzelnen Zeitquellen werden dann in Gruppen von Zeitquellen zusammengefasst, die die "gleiche" Zeit bereitstellen. Auf diese Weise kann eine Gruppe von "guten" Zeitquellen (im NTP-Jargon truechimers genannt) eine kleinere Gruppe von "schlechten" Zeitquellen (sogenannte falsetickers) überstimmen. Der sogenannte system peer wird dann aus der Gruppe der "guten" Zeitquellen selektiert.

Wenn diese ausgewählte Referenzzeitquelle irgendwann nicht mehr erreichbar sein sollte, wählt sich der NTP-Daemon die nächstbeste Referenzzeitquelle aus. Der Stratum-Wert, unter dem der NTP-Daemon im Netzwerk sichtbar ist, entspricht jeweils dem Stratum-Wert der ausgewählten Referenzzeitquelle plus 1.

Nähere Beschreibung des Auswahlverfahrens zur Gruppierung der Zeitquellen:
https://www.eecis.udel.edu/~mills/ntp/html/prefer.html

Kriterien für die optimale Anzahl der zu konfigurierenden Zeitquellen:
http://support.ntp.org/bin/view/Support/SelectingOffsiteNTPServers#Section_5.3.3.

Der NTP-Daemon liest seine Konfigurationsparameter aus einer Datei namens ntp.conf. Auf Unix-ähnlichen Systemen liegt diese Datei meist im Verzeichis /etc.

Wenn unter Windows eine aktuelle NTP-Version mit Hilfe des GUI-Installers von der Meinberg NTP-Download-Seite installiert wurde, liegt die Datei ntp.conf normalerweise in einem Verzeichnis etc\ im Installationsverzeichnis, z.B. in c:\Programme\NTP\etc.

Bei älteren Versionen von NTP für Windows wurde die Datei entweder im Verzeichnis %systemroot% oder im Verzeichnis %systemroot%\system32\drivers\etc abgelegt, wobei %systemroot% je nach Windows-Version dem Verzeichnis c:\winnt oder c:\Windows entspricht.

Normalerweise enthält die Datei ntp.conf mindestens eine oder mehrere Zeilen mit dem Keyword server .

Jede dieser Zeilen gibt eine Referenzzeitquelle an, die entweder ein anderes Gerät im Netzwerk sein kann, oder auch eine Funkuhr, die direkt an den Computer angeschlossen ist.

Referenzzeitquellen werden durch eine IP-Adresse angegeben oder auch durch einen Hostname, der durch einen DNS Nameserver aufgelöst werden kann.

Wenn es sich bei einer IP-Adresse um ein real existierendes Gerät im Netzwerk handelt, geht der NTP-Daemon davon aus, dass auf dem Gerät mit der IP-Adresse ein weiterer NTP-Daemon läuft, den er kontaktieren kann.

Außerdem verwendet NTP einige Pseudo-IP-Adressen, die normalerweise im Netzwerk nicht verwendet werden, um spezielle Zeitquellen wie Funkuhren zu adressieren.

Zum Beispiel benutzt NTP die Pseudo-IP-Adresse 127.127.8.n , um eine Funkuhr von Meinberg anzusprechen, die direkt an den Computer angeschlossen ist.

Um seine eigene Systemuhr anzusprechen, bei NTP local clock genannt, verwendet NTP die Pseudo-IP-Adresse 127.127.1.0. Diese Adresse darf nicht mit der IP-Adresse 127.0.0.1 verwechselt werden, die auch als localhost oder Loopback-Interface bezeichnet wird.

Achtung:
Einige sehr alte Versionen von NTP haben Probleme mit der DNS-Namensauflösung unter Windows, wenn das Programmpaket mit MD5-Authentifizierung compiliert wurde. In diesem Fall müssen alle IP-Adressen in der Datei ntp.conf als numerische Werte eingegeben werden (z.B. 172.16.1.1). DNS-Hostnamen wie host.domain.com können nicht verwendet werden.

Konfiguration mit Meinberg Funkuhr (Unix)

Unter Unix-ähnlichen Systemen wird der Parse-Treiber verwendet, um Funkuhren von Meinberg mit serieller Schnittstelle als Referenzzeitquelle zu verwenden. Der Parse-Treiber ist Bestandteil des NTP-Pakets, muss aber beim Compilieren des NTP-Paketes explizit aktiviert werden. Bei den gängigen Linux-Distributionen ist der Parse-Treiber in den vorcompilierten Paketen aktiviert, bei einigen älteren Solaris-Versionen jedoch nicht.

Auf der Meinberg Software Download-Seite ist ein Treiberpaket für Meinberg Einsteckkarten unter Linux verfügbar, welches es erlaubt, die Einsteckkarten zu konfigurieren sowie deren Statusinformationen anzuzeigen. Zusätzlich ermöglicht der Treiber dem NTP-Daemon unter Linux, die Referenzzeit von der Einsteckkarte anstatt über die serielle Schnittstelle zu lesen. Dieser Treiber wird nur für die Einsteckkarten benötigt, nicht jedoch für Funkuhren, die direkt über eine serielle Schnittstelle angebunden sind.

Die unten aufgeführten Konfigurationsschritte müssen von einem Benutzer mit genügend Rechten auf dem System durchgeführt werden, z. B. dem Benutzer root.

Der Parse-Treiber spricht Funkuhren als Devices mit Namen /dev/refclock-n an, wobei n ein Index von 0 bis 3 sein kann, da der Parse-Treiber bis zu 4 Funkuhren gleichzeitig verwenden kann.

Jedes der verwendeten Devices wird als symbolischer Link zu einem einem realen Device angelegt, hinter dem sich eine Funkuhr verbirgt. Meist handelt es sich bei dem realen Device um eine serielle Schnittstelle, an die eine Funkuhr angeschlossen ist, unter Linux kann der Link jedoch auch auf ein Device zeigen, hinter dem sich eine Einsteckkarte verbirgt.

Jede der Funkuhren muß in der Datei ntp.conf durch eine Zeile mit dem Keyword server und einer Pseudo-IP-Adresse 127.127.8.n angegeben werden. Dabei muß der Wert für n jeweils der Index-Nummer entsprechen, die für das oben erwähnte symbolische Device /dev/refclock-n verwendet wurde.

Auf die Pseudo-IP-Adresse folgt noch ein Parameter mode m , der den Typ der Funkuhr angibt, die unter dieser Adresse angesprochen wird. Die Tabelle unten gibt die für Funkuhren von Meinberg verwendeten Werte für den mode-Parameter und die zugehörigen Funkuhr-Typen an:

Wenn beispielsweise eine einzelne Funkuhr an der ersten seriellen Schnittstelle des Computers angeschlossen ist, wird zunächst ein symbolischer Link angelegt, der auf die erste serielle Schnittstelle verweist. Unter Linux hat diese Schnittstelle oft den Namen /dev/ttyS0, kann aber je nach Unix-System auch anders heißen:

ln -s /dev/ttyS0 /dev/refclock-0

Wenn eine Einsteckkarte mit dem Meinberg Linux-Treiber als Referenzzeitquelle für NTP verwendet werden soll, muß der symbolische Link auf die Gerätedatei zeigen, hinter der sich die Einsteckkarte verbirgt:

ln -s /dev/mbgclock0 /dev/refclock-0

Achtung: Aktuelle Versionen des Linux-Treibers erzeugen symbolische Links /dev/refclock-* automatisch durch das Linux udev-System. Bei älteren Versionen des Treibers (vor v3.0.0) dagegen mußte der Link manuell angelegt werden und die Gerätedatei für die Einsteckkarte hieß /dev/mbgntp. Im Zweifelsfall gibt die README- oder LIESMICH-Datei des Treiberpaketes Auskunft.

Im nächsten Schritt wird die Datei ntp.conf angepaßt, um dem NTP-Daemon mitzuteilen, welche Funkuhr er verwenden soll.

Die Datei muß eine server-Zeile für das Gerät refclock-0 enthalten, das oben angelegt wurde. Wenn die Funkuhr das Meinberg Standard-Zeittelegramm mit 9600 Baud und Datenformat 7E2 ausgibt, muß der Mode-Parameter laut der Tabelle oben mit 2 angegeben werden. Wenn der Linux-Treiber für eine Einsteckkarte verwendet wird, muss immer mode 2 verwendet werden:

server 127.127.8.0 mode 2

Zusätzlich sollte ein server-Eintrag für die Local Clock angelegt werden, die als Fallback-Reserve genutzt werden kann, wenn keine andere Referenzzeitquelle mehr verfügbar sein sollte. Da die Local Clock nicht sehr genau ist, sollte ihr Stratum auf einen niedrigen Wert gesetzt werden, z.B. Stratum 12:

server 127.127.1.0# local clock
fudge 127.127.1.0 stratum 12

Um die Änderungen wirksam werden zu lassen, muß der NTP-Daemon neu gestartet werden.

Wenn nach dem Start des NTP-Daemons die Ausgabe des Befehls ntpq -p eine Referenzzeitquelle mit der Bezeichnung generic auflistet, unterstützt der NTP-Daemon die Funkuhr.

Wenn keine Referenzzeitquelle mit der Bezeichnung generic angezeigt wird, wurde das NTP-Paket eventuell ohne Unterstützung für die Parse-Uhren compiliert, oder dem NTP-Daemon wird der Zugriff auf die Gerätedatei verwehrt ("Permission denied"). Die Syslog-Meldungen des NTP-Daemon nach dem Start geben Aufschluß über den tatsächlichen Grund für das Problem.

Der Grund für Meldungen "Permission denied" kann bei aktuellen Linux-Distributionen eins der Programme AppArmor oder SELinux sein, die den Zugriff auf Dateien und Geräte kontrollieren und beschränken. Einzelheiten dazu und wie man das Problem beseitigt finden sich den Dateien README und LIESMICH aus dem Linux-Treiberpaket.

Wenn der NTP-Daemon ohne Unterstützung für die Parse-Uhren compiliert wurde, muß das NTP-Paket auf dem Zielsystem neu compiliert werden. Dazu muß ein Compiler auf dem System installiert sein, außerdem müssen die Programmquellen vorliegen, die in der Standard-NTP-Distribution enthalten sind.

In dem Beispiel unten ist name der Hauptname einer NTP-Distribution. NTP-Distributionen stehen als Archive mit Namen name.tar.gz zum Download im Internet bereit und müssen auf dem Zielsystem entpackt werden:

tar xvzf name.tar.gz

Durch diesen Befehl wird ein neues Verzeichnis name angelegt, das noch weitere Unterverzeichnisse enthält . Um das Paket zu compilieren, wechselt man in das neu angelegte Verzeichnis, wo man die Befehle configure und make aufruft, um das Programmpaket zu compilieren:

cd name
./configure --enable-MEINBERG
make

Nachdem die Compilierung erfolgreich beendet wurde, liegt jedes der erzeugten Programme in einem Unterverzeichnis mit dem gleichen Namen wie das Programm selbst. Wenn sichergestellt ist, dass nicht bereits ein anderer NTP-Daemon läuft , kann der neu erzeugte Daemon gestartet werden. Wenn es sich um ein NTP-Paket mit der Version 4.x handelt, lautet der Befehl

ntpd/ntpd

Im Fall einer NTP-Version 3.x dagegen lautet der Befehl

xntpd/xntpd

Der Befehl ntpq -p kann verwendet werden, um die korrekte Funktionsweise zu überprüfen. Wenn alles wunschgemäß arbeitet, können die neuen ausführbaren Dateien in das Zielverzeichnis kopiert werden, wo sie beim Start des Systems gefunden werden. Die Installation der Programme kann normalerweise geschehen durch Eingabe des Befehls

make install

Falls vorher bereits ein NTP-Paket installiert war, muß sichergestellt sein, dass die alten NTP-Programme gelöscht oder von den neuen Programmen überschrieben werden, so dass beim Systemstart nicht versehentlich der alte NTP-Daemon gestartet wird. Der neue Daemon muß in dem Verzeichnis liegen, wo die Strartup-Scripts ihn erwarten.

Besonders bei einem Versionssprung von NTP v3.x auf NTP v4.x sollte die geänderte Namensgebung berücksichtigt werden, etwa von xntpd nach ntpd.

Konfiguration mit Meinberg Funkuhr (Windows)

Auf Windows-Systemen werden die meisten Funkuhren von NTP noch nicht direkt unterstützt. Stattdessen kann der Treiber von Meinberg eingesetzt werden, um die Windows-Systemzeit zu synchronisieren. Der NTP-Service stellt dann lediglich die synchronisierte Windows-Systemzeit im Netzwerk bereit.

Wenn NTP für Windows mit Hilfe des GUI-Installers von der Meinberg NTP-Download-Seite installiert wird und das Setup-Programm das bereits installierte Treiberpaket findet, schlägt der Installer eine entsprechende NTP-Konfiguration mit dem Titel "Follow Meinberg Time Service" vor.

Für diese Konfiguration muß die Datei ntp.conf die folgenden Zeilen enthalten:

server 127.127.1.0# local clock
fudge 127.127.1.0 stratum 0 # disciplined by radio clock

Da die Windows-Systemzeit von einer Funkuhr synchronisiert wird, kann in diesem Fall der Stratum-Wert der Local Clock hoch auf 0 gesetzt werden. Der NTP-Server ist dann als Stratum-1-Server im Netzwerk sichtbar.

Anders als vormals auf dieser Seite beschrieben, sollte die Konfigurationsdatei nicht die Zeile disable ntp enthalten. Wenn diese Zeile enthalten ist, wird der NTP-Server eventuell nicht von seinen Clients akzeptiert.

Ebenso sollte kein driftfile angegeben werden. Wenn bereits eine Datei mit dem Namen ntp.drift auf dem Rechner existiert, sollte diese Datei gelöscht werden. Andernfalls könnte der NTP-Service versuchen, basierend auf dem Wert aus dem Driftfile die Drift der Systemzeit zu kompensieren. Damit würde der NTP-Service gegen den Funkuhr-Treiber arbeiten, wodurch nur eine schlechte Zeitsynchronisation erzielt würde.

Konfiguration ohne Funkuhr

Die Konfiguration der Computer ohne eigene Funkuhr ist sehr einfach. Für jeden Timeserver im Netzwerk, der als Referenzzeitquelle genutzt werden soll, muß die Datei ntp.conf eine server -Zeile mit der IP-Adresse oder dem Hostname des Gerätes enthalten. Dabei sollten Timeserver mit gutem Stratum-Wert angegeben werden, die auf kurzen Netzwerk-Wegen erreichbar sind.

Zusätzlich kann auch hier die Local Clock des Computers angegeben werden, die als Fallback-Reserve genutzt werden kann, wenn keine andere Referenzzeitquelle erreichbar sein sollte.

Da die Local Clock hier nicht durch ein anderes Programm synchronisiert wird, sollte sie auf einen relativ schlechten Stratum gesetzt werden, z.B. 12. Dadurch ist sichergestellt, dass Timeserver im Netz mit besserem Stratum bevorzugt werden:

server 127.127.1.0# local clock
fudge 127.127.1.0 stratum 12# not disciplined
server ntp_server_1 iburst
server ntp_server_2 iburst
server ...

Im Beispiel oben stehen ntp_server_1, ntp_server_2, usw, für den Hostname oder die IP-Adresse existierender Timeserver. Das Keyword iburst sorgt für eine schnelle Erstsynchronisierung beim Programmstart. Sehr alte NTP Versionen unterstützen das Keyword iburst nicht.

Zusätzliche Konfigurationsparameter

Im laufenden Betrieb ermittelt der NTP-Daemon, wie sehr die Systemzeit des Computers von der Referenzzeit wegdriftet. Der Daemon kann diesen ermittelten Wert in einer Datei speichern, von wo er ihn beim nächsten Start wieder lesen kann.

Hierdurch wird die Dauer der Zeitsynchronisierung beim erneuten Start des Daemons verkürzt. Um diese Möglichkeit zu nutzen, muß der Name des Driftfiles in einer Zeile der Datei ntp.conf angegeben werden, z.B.:

driftfile /etc/ntp.drift

Achtung: Wenn das NTP-Programm unter Windows zusammen mit der Meinberg-Treibersoftware arbeitet, sollte kein Driftfile angegeben werden. Siehe Abschnitt Konfiguration mit Meinberg Funkuhr (Windows).

Es gibt eine Anzahl weitere Optionen, die in der Konfigurationsdatei eingestellt werden können. Nähere Informationen dazu findet man in der NTP-Dokumentation.

Das Kommandozeilen-Programm ntpq kann dazu benutzt werden, den Status des NTP-Daemons auf dem eigenen Computer oder auch auf einem anderen Computer im Netzwerk zu überprüfen.

ntpq kann in einem interaktiven Modus oder im Batchbetrieb arbeiten. Im Batchbetrieb führt ntpq einen Befehl aus und kehrt dann zur Eingabeaufforderung zurück. Bei Aufruf des Programms mit dem Parameter -p ('peers') wird eine Tabelle mit Informationen über die verwendeten Referenzzeitquellen ausgegeben. Um den Status des NTP-Daemons des eigenen Computers anzugeben, wird einfach der Befehl

ntpq -p

verwendet. Man kann auch den Hostname oder die IP-Adresse eines Gerätes im Netzwerk angeben, um sich den Status des dort laufenden NTP-Daemons anzeigen zu lassen:

ntpq -p ntp_server_1, ntp_server_2, ...

Die Ausgabe des Programms sollte etwa so aussehen:

remote		refid	st	t	when	poll	reach	delay	offset	jitter
======================================================================================
LOCAL(0)	.LCL0.	12	l	11	64	1	0.000	 0.000	0.977
*GENERIC(0)	.DCFa.	0	-	24	64	377	0.000	 0.050 	0.003
+172.16.3.103	.PPS.	1	u 	13	64	1	0.701	 0.228	0.977

Die Tabelle enthält je eine Zeile für jede in der Datei ntp.conf angegebene Referenzzeitquelle. Im Beispiel oben sind das 3 Zeitquellen: Die eigene Local Clock, eine DCF77-Funkuhr als refclock-0, und ein Timeserver im Netzwerk unter der IP-Adresse 172.16.3.103.

Wenn das erste Zeichen einer Zeile kein Leerzeichen ist, dann enthält es eine Kennung, wie der NTP-Daemon diese Zeitquelle bewertet. Direkt nach dem Start des Daemons enthalten alle Zeilen am Anfang ein Leerzeichen. Der NTP-Daemon benötigt mehrere Abfragezyklen (polling cycles), um die angegebenen Zeitquellen zu prüfen und eine davon als diejenige auszuwählen, auf die er sich synchronisiert.

Ein Stern * als erstes Zeichen einer Zeile kennzeichnet die Referenzzeitquelle, auf die sich der NTP-Daemon zur Zeit synchronisiert, das Pluszeichen + kennzeichnet qualitativ hochwertige Zeitquellen, die ebenfalls als Referenzzeitquelle in Frage kommen, wenn die aktuell genutzte Zeitquelle nicht mehr verfügbar sein sollte (candidates).

Die Spalt remote zeigt den (Pseudo-) Hostname oder die IP-Adresse der Referenzzeitquelle. Dabei bezeichnet z.B. LOCAL die Local Clock, GENERIC(0) das Device refclock-0 des Parse-Treibers.

Die refid gibt den Typ der Referenzzeitquelle an, dabei bedeutet z.B. LOCAL oder LCL wiederum Local Clock, .DCFa. ist ein Standard-DCF77-Empfänger , und .PPS. bedeutet, dass die Synchronisierung über ein Hardware-PPS-Signal (Sekundenimpuls) erfolgt. Andere Kennungen sind möglich, abhängig von der Art der Referenzzeitquelle.

Die Spalte st zeigt die Stratum-Nummer der Referenzzeitquelle an. Im Beispiel oben hat die Local Clock den Stratum 12, der Timeserver mit der IP-Adresse 172.16.3.103 hat den Stratum 1, das beste, was über das Netzwerk zu sehen ist, und die Funkuhr hat Stratum 0, daher wird die Funkuhr als Referenzzeitquelle verwendet. Da die Funkuhr Stratum 0 hat, wird der eigenen NTP-Daemon von Clients im Netzwerk als Stratum-1 Timeserver gesehen.

Der Wert in der Spalte when zeigt die Anzahl der Sekunden seit dem letzten Polling-Zyklus an. Wenn dieser Wert den in der Spalte poll gezeigten Wert erreicht, führt der NTP-Daemon einen Zeitvergleich mit der entsprechenden Referenzzeitquelle durch und setzt den Wert für when wieder auf 0. Die Ergebnisse der Zeitvergleiche werden gefiltert und dienen als Maß für die Qualität und Erreichbarkeit einer Zeitquelle.

Die Spalte reach zeigt, ob die Referenzzeitquelle während der letzten Polling-Zyklen erreichbar war. Die Zahl ist ein 8-Bit-Register, dessen Wert historisch bedingt in oktaler Schreibweise angezeigt wird. Wenn der NTP-Daemon gerade gestartet ist, ist der reach-Wert für alle Zeitquellen 0. Nach jedem erfolgreichen Polling-Zyklus wird eine '1' von rechts in das Register hineingeschoben, so dass nach dem Start des Daemons nach jedem erfolgreichen Pollingzyklus nacheinander die Werte 0, 1, 3, 7, 17, 37, 77, 177, 377 angezeigt werden. 377 ist der hächstmögliche Wert, der aussagt, dass die letzten 8 Polling-Zyklen erfolgreich waren.

Erfolgreich bedeutet, dass Daten mit der Zeitquelle ausgetauscht werden konnten, und dass die Referenzzeitquelle selbst auch synchron zu ihrer eigenen Zeitquelle war. Im Fall einer Funkuhr bedeutet das konkret, dass der Polling-Versuch als nicht erfolgreich bewertet wird, wenn die Funkuhr nicht synchron zu ihrem Sender ist, z.B. weil das Antennenkabel abgezogen wurde, oder aber auch, wenn keine Daten empfangen werden können, weil z.B das serielle Kabel zu einer externen Uhr abgezogen wurde.

Der NTP-Daemon entscheidet erst nach mehreren erfolgreichen Polling-Zyklen, ob er eine Zeitquelle als Referenz für sich akzeptiert, die wie oben beschrieben durch einen '*' gekennzeichnet wird.

Die Spalten delay, offset und jitter zeigen einige Zeiten an, die aus den gefilterten Daten der Polling-Zyklen gewonnen wurden.

In einigen Versionen von ntpq wird die letzte Spalte mit disp (dispersion) bezeichnet statt mit jitter. Alle Werte sind in Millisekunden angegeben.

Der Wert delay ist die Laufzeit zwischen der Anfrage des NTP-Daemons bis zum Eintreffen der Antwort.

Der Wert offset zeigt die Zeitdifferenz zwischen der Referenzzeit und der eigenen Systemzeit.

Der Wert jitter gibt die Größenordnung der Schwankungen zwischen einzelnen Zeitvergleichen an.

Meinberg NTP Download-Seite

Eine vorcompilierte Version von NTP für Windows findet man auf unserer NTP-Download-Seite.

NTP Homepage

Die Original-Distribution im Quelltext und eine Flle von Informationen und weiterführenden Links zu NTP findet man auf der NTP-Homepage http://www.ntp.org.

NTP Online-Dokumentation

Die komplette NTP-Documentation im HTML-Format ist in der Archiv-Datei des NTP-Paketes enthalten. Die aktuellste Version der Dokumente ist auch online verfügbar auf der NTP-Homepage http://www.ntp.org.

Von NTP-Benutzern zusammengetragene Informationen, ein Bug-Reporting-System, Mailinglisten usw. stehen auf der Webseite des NTP Public Services Project unter http://support.ntp.org zur Verfügung.

NTP Usenet Diskussionen

Der interessante News-Artikel NTP advice given von David Dalton diskutiert viele Eigenschaften beim Einsatz von NTP, besonders unter HP-UX.

Es existiert auch eine Newsgroup comp.protocols.time.ntp in der Leute aus der ganzen Welt über NTP diskutieren oder Fragen zu speziellen Konfigurationen stellen. Ältere Artikel aus der Newsgroup kann man nach bestimmten Schlüsselworten sortiert suchen lassen bei Google https://groups.google.com/advanced_group_search

RFCs mit dem Thema NTP and Zeitsynchronisierung im Netzwerk