Einführung Zeitsynchronisation

Einführung in die Grundlagen der Zeitsynchronisation

Um auf allen Systemen die gleiche Uhrzeit zu haben
Um bei Logfileauswertungen von verschiedenen Systemen mögliche Zusammenhänge erkennen zu können
Um bei Zeiterfassungssystemen keine Probleme zu bekommen (mehr als ein Erfassungssystem)
Um in Verzeichnisdiensten keine unterschiedlichen Zeitstempel für den gleichen Eintrag zu bekommen
Vermeidung von Schwierigkeiten bei Zeitumstellungen (z.B.: Sommerzeit)
Vermeidung von falschen Absende- und Ankunftszeiten beim Dienst e-Mail (die Ankunftszeit sollte nicht früher als die Absendezeit sein)

Klassisch nach der Uhrzeit zu fragen, funktioniert nur wenn die Übetragungszeit der Information kürzer als die maximal zulässige Ungenauigkeit ist
In Netzwerken ist die Übertragungszeit meist zu lang und vor allem nicht konstant (Jitter)
Es benötigt daher Verfahren, um sowohl die Laufzeit als auch die Schwankungen in der Laufzeit "herausrechnen" zu können
Die Laufzeit kann mit Hilfe der RTT (round trip time) gemessen werden (Messung der Laufzeit für Hin- und Retourübetragung)
Die Schwankungen der Laufzeit können mit Hilfe der Mittelung vieler Übertragungen eruiert werden

Kurzzeitige Netzwerkausfälle müssen mit Hilfe einer möglichst genauen lokalen Uhr überbrückt werden
Die lokale Uhrzeit darf nicht in einem großen Schritt an die Netzwerkzeit angepasst werden, sondern in vielen kleinen, um zu vermeiden, daß Zeitstempel doppelt vergeben werden bzw. Lücken in Log-Dateien entstehen
Wenn die Netzwerk-Zeit bei mehreren Anfragen konsistent bleibt, wird die eigene Uhrzeit in einem kleinen Schritt in Richtung dieser Zeit korrigiert
Initial kann auch einmalig die Netzwerk-Zeit direkt in die lokale Uhr übernommen werden (unter Berücksichtigung der Zeitzonen; das wird vor allem bei Clients verwendet)

Abstimmung - Alle Teilnehmer einigen sich auf eine gemeinsame Zeit (Mittelwert der Zeiten) und passen die eigene ein wenig daran an
Dikatorisch - Einer bestimmt die Zeit und alle anderen übernehmen diese
Hierarchisch - Server holen die Zeit von einem Zeitnormal und geben Sie an Clients weiter (mehrere Stufen möglich)
Hybrid - Eine Mischung aus obigen Modellen

ntp - Network Time Protokoll (RFC 5905)
NTP verwendet UDP-Port 123
Ein NTP-Client frägt bei einem NTP-Server nach Datum und Uhrzeit (viele aufeinanderfolgende Anfragen)

Stratum gibt die Entfernung zu einem externen Zeitnormal (z.B.: Atomuhr, GPS) an
Die Stratum-Werte und ihre Bedeutung:

Wert Bedeutung

0 Nicht spezifiziert oder ungültig

1 Primärer Server mit direkter Verbindung zur Zeitquelle

2-15 Sekundärer Server (Zeit via ntp)

16 Nicht synchronisiert

17-255 Reserviert

Wert	Bedeutung
0	Nicht spezifiziert oder ungültig
1	Primärer Server mit direkter Verbindung zur Zeitquelle
2-15	Sekundärer Server (Zeit via ntp)
16	Nicht synchronisiert
17-255	Reserviert

pool.ntp.org, at.pool.ntp.org, europe.pool.ntp, .... (aus dem NTP-Projekt bzw. Pool-Servers)
Bei mehreren Servern aus dem gleichen Pool: z.B.: 0.at.pool.ntp.org, 1.at.pool.ntp.org, ...
time.metrologie.at, bevtime1.metrologie.at, bevtime2.metrologie.at (BEV)
ts1.aco.net, ts2.aco.net (ACOnet)
ptbtime1.ptb.de, ptbtime2.ptb.de, ptbtime3.ptb.de (PTB bzw. PTB-Uhr)
Providerspezifische: ntp.a1.net (A1), ntp.sil.at ("3"), ntp.inode.at (Magenta)

Danke für Ihre Aufmerksamkeit