orm@doc-tcpip.org

Erstellt: Juni 2001 - Letzte Modifikation: November 2002

[ Main | Local ]


Allgemeines zum Network Time Protocol


Die RFCs zum Thema

RFC1305 Network Time Protocol (Version 3) Specification, Implementation
RFC1129 Internet Time Synchronization: The Network Time Protocol
RFC2030 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI
RFC1589 A Kernel Model for Precision Timekeeping
Alle RFC bekommt man vom RFC-Editor (www.rfc-editor.org) oder vom RFC Netserver (rfc.net).

Wichtige Links

Die Seiten von David Mills von der University of Delaware (www.eecis.udel.edu/~ntp), der NTP entwickelt. Hier finden sich auch die Implemetationen (ntpd, xntpd) sowie viele, interessante Information zum Thema. Die NTP-Homepage (www.ntp.org) ist übrigens ein Link auf die erste Seite.

DCF77 Funkuhren gibt es von Meinberg (www.meinberg.de) oder von Hopf (www.hopf-time.com).

Wie das Network Time Protocol (NTP) funktioniert

Man sollte sich einmal das Prinzip klargemacht haben - dann fällt der Umgang mit dem Protokoll bzw. seinen Implementationen deutlich leichter. Neben NTP gibt es noch den time-Deamon. In diesem Ansatz synchronisieren Maschinen tatsächlich gegeneinander, und aus der Zeit aller wird "demokratisch" eine gemeinsame, gemittelte Zeit berechnet, die dann von allen angestrebt wird.

Das ist beim NTP fundamental anders, und es ist wichtig, das zu begreifen: Das NTP synchronisiert ein System gegen eine externe, exakte Zeitquelle (UTC). Es erfolgt primär kein Abgleich gegen andere Systeme. Das sich Rechner in einem Netz so synchronisieren ist eigentlich ein Nebeneffekt der Bestrebung des einzelnen Rechners, sich UTC möglichst gut anzunähern. Daher ist NTP auch hierarchisch organisiert und völlig auf eine Zeitquelle ausgerichtet. Selbst bei der Angabe von mehreren "Peers" werden diese nur als mehr oder minder zuverlässige Quelle von UTC angesehen und es wird immer nur gegen einen bestimmten abgeglichen - der allerdings wechseln kann.

Das Protokoll sieht keinerlei Möglichkeiten vor, verschiedene Ansichten über die momentante Zeit partnerschaftlich zu klären (wie der Time-Deamon) - es kann nur eine richtige und wahre Zeit geben. Und von der anerkannten Quelle dieser Standard-Zeit sind die Clienten hierarchisch absteigend in Ebenen eingeteilt, das Stratum. Das Stratum ist nichts anders als die Anzahl der Hops zwischen der Quelle und dem Client. Man geht von der Annahme aus, das die Zeitinformation präziser ist, wenn man näher an der Quelle sitzt. Das Stratum 1 hat direkten Zugang zur Quelle, während ein Stratum 2 Client die Information über einen Stratum 1 Server bekommt (gegen den er sich nicht synchronisiert - er bekommt nur die Zeitinformation über ihn). Der Stratum 2 Client kann nun wieder Server für Stratum 3 Clients sein - und so weiter.

Die Synchronisation mit UTC erfolgt über die Mitteilung von aktuellen Zeitmarken (Timestamps). Da der Unterschied (Offset) zwischen Server und Client per se unbekannt ist, muß die Laufzeit der Information bekannt sein. Das geht auf dem Internet nur in einer Näherung. Man nimmt die Rundlaufzeit der Anfrage und hofft, das Hin- und Rücklaufzeit im Mittel gleich sind. Der Client ist bestrebt, einen Server mit möglichst niedrigem Stratum zu wählen und versucht, sich an diese Zeitinformation anzugleichen. Allerdings führt er eine eigene Statistik und vergleicht die empfangene Information mit seiner Statistik über die letzten 8 Pakete - so ist der Client in der Lage, einen "kranken" (insane) Server auszumachen. Schließlich will der Client gegen UTC synchronisieren, und das ist eindeutig. Er wird versuchen, die Zeitinformation eines anderen Servers zu benutzen. Bei dieser Entscheidung hilft der Server mit, da er einmal sein Stratum mitteilt, angibt, für wie präzise er seine Zeitinformation hält und die Rundlaufzeiten meßbar sind.

Diese Verhalten hängt auch vom Typ (Mode) der Verbindung ab. Das NTP erlaubt eine Client/Server Beziehung sowie Broadcast und Multicast Beziehungen. Die beteiligten Maschinen werden als Peers bezeichnet. Die Client/Server Beziehung kann symmetrisch sein, in diesem Fall geben sich die Peers gegeseitig Zeitinformation. Die Broadcast und Clientbeziehungen sind asymmetrisch.

Wie genau man die Zeit bekommt

Das ist stark Hardwareabhängig. Mit einer RISC Architektur wird die Präzision von der benutzten Funk-Uhr und dem Interface bestimmt, sollte aber bei einigen Millisekunden liegen. Mit spezieller Hardware kommt man wohl in die Größenordnung von einigen hundert Mikrosekunden - wers so genau braucht.

Die Implementation des NTP ist der nächste Faktor, der die Genauigkeit beeinflußt. Der xntpd z.B. benutzt einen 64-Bittigen Zeitstempel, 32 Bit für die Sekunden und 32 Bit für die Fraktionen. Weiterhin sind die zugrundeliegende Arithmetik wichtig. So rechnen Computer bei Fließkomma Rechungen technisch bedingt falsch.

Wie sicher ist das Ganze?

In einem sicheren Netz ist eine exakte Zeit sehr wichtig, da alle Authentifizierungs-Services mit Zeitfenstern arbeiten. Ein Verbiegen der Zeit ist somit eine Möglichkeit des Angriffes. Die aktuellen Implementationen des NTP erlauben Keywörter, sodaß man unerlauben Zugriff bzw. unerlaubten Service unterbinden kann. Allerdings ist es nicht möglich, den Inhalt zu verschlüßeln. Das ist aber in der neuen NTP Version 4 berücksichtigt. Der wichtigste Punkt ist, daß all diese Algorithmen Zeit kosten, also per se die Genauigkeit der Synchronisation verschlechtern.

Ein ganz anderer Punkt sind Zählerüberläufe. Die Zeitskala des NTP beginnt am 1. Januar 1900 (Null Uhr). Es steht ein 32 Bit-Zähler für Sekunden zur Verfügung, also schlägt der Zähler alle 136 Jahre um. Diese Zeitspanne wird als Era bezeichnet. In diesem Fall ist das Ganze unkritisch, da es Aufgabe des Betriebssystemes ist, aus dem Sekundezähler die Zeit zu ermitteln. Das NTP hat keinerlei Kenntnis von Tagen, Jahren oder Jahrhunderten.

Der xntpd und seine Utilities

Die weitverbreiteste Implementation des NTP ist xntpd von David Mills (University of Delaware). Sie kommt mit einer Reihe Utilities. Sehr nützlich ist das Kommando xntpdc, da man damit viele Informationen zum Troubleshooten bekommt. Das Kommando ntptrace ist dem traceroute-Kommando ähnlich. Es erlaubt, eine Kette von NTP-Servern bis ins Stratum 1 zurückzuverfolgen. Mit ntpdate kann man Zeit und Datum setzen, ohne xntpd laufen zu lassen. Als letztes Werkzeug wird meist noch ntpq mitinstalliert. Mit diesem Kommando kann man den xntpd unter Benutzung von Mode 6 Control Messages abfragen.

Das Format eines NTP-Paketes

Die NTP Messages werden mit UDP als Transportprotokoll übertragen. Hier das Format eines NTP-Paketes:

.   0                   1                   2                   3
.   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.  |LV |VN   |Mode |   Stratum     |      Poll     |   Precision   |
.  +---------------+---------------+---------------+---------------+
.  |                         Root Dispersion                       |
.  +-------------------------------+-------------------------------+
.  |                    Reference Clock Identifier                 |
.  +-------------------------------+-------------------------------+
.  |                      Reference Timestamp                      |
.  +-------------------------------+-------------------------------+
.  |                      Originate Timestamp                      |
.  +-------------------------------+-------------------------------+
.  |                        Receive Timestamp                      |
.  +-------------------------------+-------------------------------+
.  |                       Transmit Timestamp                      |
.  +-------------------------------+-------------------------------+
.  |                   Authenticator (optional)                    |
.  +-------------------------------+-------------------------------+
.  |                           .........                           |
.  +-------------------------------+-------------------------------+
.

Der NTP-Zeitstempel

Eine interessante Frage ist, wie man den 64-Bit NTP Zeitstempel zu verstehen hat. Die 64 Bit zerfallen in zwei 32 Bit Werte, wobei die ersten 32 Bit die Sekunden sind und die zweite Hälfte die Sekunden-Fraktionen.

 
0         1         2         3 .        4         5         6
01234567890123456789012345678901.23456789012345678901234567890123 
.                                1/2 Sek                         
.                                 1/4 Sek
.                                  1/8 Sek 
.                                          1/2048 Sek

Das Bit 33 entspricht also einer halben Sekunde, Bit 34 einer viertel Sekunde etc.
Übrigens startet NTP Epoch am 1.1.1900, zählt also die Sekunden seit diesem Tag. Nichts ist schöner als ein Beispiel. Mit xntpdc -c sysinfo finde ich den aktuellen NTP-Zeitstempel:
   
reference time:       c16fcd61.c117c5ef  Sun, Nov  3 2002 17:29:21.754

Da mache ich erstmal die Binäre-Darstellung draus:
 
elbueno:~ # bc
scale=64
obase=2
ibase=16
C16FCD61
11000001011011111100110101100001
C117C5EF
11000001000101111100010111101111     

Um zu prüfen, ob es stimmt, konvertiere ich Hex nach Dezimal und habe so die Sekunden seit dem 01.01.1900. Die Teile ich dann durch 31536000, was ungefähr die Sekunden eines Jahres sind:
 
elbueno:~ # bc
scale=64
ibase=16
C16FCD61
3245329761    
 
elbueno:~ # bc
scale=64
ibase=16
3245329761/31536000
102.9087316

Das kommt prima hin, denn wenn ich vom 1.1.1900 102 Jahre weitergehe, komme ich in 2002 raus. Die Dezimalstellen sind jetzt das laufende Jahr, und mir fehlen noch 58 Tage bis nach 2003. Also:
 
elbueno:~ # bc
scale=64      
31536000*0.9087316
28657759.7376000
28657759/86400
331.68702546296296

Das kann jetzt nicht sein.. ein Jahr hat 365 Tage, plus den 58 fehlenden komme ich auf 389. Funktioniert NTP nicht? Nach einigem Überlegen ist mir dann eingefallen, das es ja alle 4 Jahre Schaltjahre gibt, die einen Tag mehr haben. Bei 102 Jahre sind das rund 25 Tage, also darf ich von den 389 Tagen 25 abziehen und komme auf 364. Das klingt gut..

Wie der NTP-Algorithmus funktioniert

Ein genaueres Verständnis des NTP-Algorithmus ist zum erfolgreichen Einsatz, besonders wenn Fehler auftreten, sehr wichtig. Es werden auf die Zeitinformation, die der Client vom Server erhält, eine Reihe aufwändige, statistische Methoden angewandt, um so eine gute Zeitquelle zu finden. Weiterhin wird die erfolgte Syncronisation dauernd überwacht und nachgeregelt. Dabei wird durch ein Auslese-Verfahren verhindert, das sich die Zeit von einem festen Zeitnormal entfernt. Diese Gefahr besteht beim time-Protokoll durchaus, da "demokratisch" über die gemeinsame Zeit entschieden wird.

NTP - Der Algorithmus in Schritten

Aus der Sicht des NTP-Client werden folgende Schritte nach Empfang eines Paketes durchlaufen. Dabei ist zu beachten, das NTP vorraussetzt, daß mehrere Server zur Zeitinformation beitragen. Die Schritte vereinfachen sich natürlich, wenn nur gegen eine Quelle syncronisiert wird - die Qualität der Zeit sinkt dann entsprechend.

Abschätzen der Abweichung (Offset) und des Fehlers (Error)

Es werden maximal 64 Server in die Berechnung einbezogen, von denen maximal 10 in den Pool der potentiellen Syncronisations-Partner gelangen.

NTP ermöglicht die Syncronisation zu UTC und die Ermittlung eines geschätzten Fehlerbereiches. Dieser Wert ist die Dispersion, der geschätzte, maximale Fehler einer gegebenen Verschiebung (Offset) der Zeit zwischen Client und Server. In die Dispersion fließt die Verzögerung (Delay), die im Netzwerk auftritt, und der Fehler (Error) der Messung.

Der Offset ist die Hälfte der Differenz der Laufzeiten der Pakete Client-Server und Server-Client. Die Rechenzeit wird dabei abgezogen, nur die Netzwerk-Laufzeit zählt. Der Offset ist der Wert in Sekunden, um den sich die Client-Uhr von der Server-Uhr unterscheidet.

Der Delay ist die Rundlaufzeit des Paketes ohne die Rechenzeit, also reine Zeit, die dasPaket auf dem Netzwerk war.

Der Error ist ein Wert in Sekunden, der Frequenzungenauigkeiten und Messfehler berücksichtigt.

Die Dispersion ist die Hälfte des Delays plus dem Error, also die maximale Unsicherheit des Offsets eines Client.

Hier wird es vielleicht deutlicher:

 
.
.                                         (Dispersion) 
.                                      [+++++++++++++++++] 
.                        |             |
.                   #####|#############|##################
.                   # In diesem Breich muß die Anpassung #
.                   #      der Client-Uhr liegen         # 
.                   #####|#############|################## 
.                        |             |
.                        |           (Offset zur Serverzeit)
.                        | 
.                      (Aktuelle Client Zeit)
.

Ermittlung von Offset und Dispersion
Der Client sendet ein Paket an den Server, das er mit einem Zeitstempel C1 versehen hat. Der Server empfängt dieses Paket und versieht es mit seinem Eingangs-Zeitstempel S1. Danach bildet der Server das Antwort-Paket mit der Dispersion seines Root-Servers und versieht es kurz vor dem Senden mit seinem Ausgangs-Zeitstempel S2. Das eliminiert die Rechenzeit des Servers. Der Client empfängt das Paket und schreibt seinen Eingangs-Zeitstempel C2.

Die Berechung sieht daher folgendermaßen aus:

Der Client muß also im Bereich von Offset - Dispersion bis Offset + Dispersion angepasst werden. NTP geht davon aus, daß die wahre Abweichung in der Mitte dieses Bereiches liegt und passt die Uhr entsprechend an. Die Dispersion wird mit zunehmender Syncronisation immer geringer. Sind die Uhren syncron, dann ist es ein direkter Ausdruck für die Rundlaufzeit und den Error.


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