Kurz erklärt: Das Precision Time Protocol
Wie genau
Während der Golden Oldie NTP für die Synchronisation übers Internet gedacht ist, versucht das Precision Time Protocol eine präzise Zeitabstimmung im LAN zu erreichen.
Zuerst zum Klassiker: Das Network Time Protocol (NTP) des RFC 958 bereichert die Welt seit über dreißig Jahren, die in RFC 5905 beschriebene Version 4 immerhin seit 2010. Das mehrschichtig arbeitende Protokoll unterteilt Geräte in Primärserver, Sekundärserver und Clients. Erstere heißen Stratum 1 und sind direkt mit der Zeitgeberquelle, dem Stratum 0, verbunden. Quellen können sein eine lokale Atomuhr oder ein Zeitzeichenempfänger, der die Zeit etwa vom deutschen Zeitzeichensender DCF77, einem Satelliten- (GNSS) oder Funk-Navigationssystem wie LORAN bekommt. Sekundäre Server in der Kette heißen Stratum 2, Stratum 3 und so weiter. Klienten passen ihre Uhr an und kümmern sich sonst nicht weiter um die Zeitgeberei.
Da die Uhr weiterläuft, während sich die NTP-Pakete durchs Netz bewegen, müssen die Empfänger die Laufzeit auf die vom Sender genannte Zeit aufaddieren. NTP arbeitet mit den vier in der Tabelle aufgelisteten Variablen. Nach dem Absenden eines UDP-Pakets an den Server und dem Entgegennehmen der Antwort kann der Client die Paketlaufzeit berechnen und eine Zeitanpassung vornehmen. Dabei kommen die zwei Formeln zum Einsatz. Theta beschreibt den Zeitunterschied zwischen den Maschinen, während Delta den Roundtrip-Delay liefert:
theta = T(B) - T(A) = 1/2 * [(T2-T1) + (T3-T4)] delta = T(ABA) = (T4-T1) – (T3-T2).
Stehen mehrere Server zur Verfügung, erlaubt Marzullos Algorithmus das Errechnen eines „optimalen Mittelwerts“. Diese neue Zeit könnte NTP direkt in das Zeitregister schreiben, das aber würde zu Zeitsprüngen und anderen Unwegsamkeiten führen. Saubere Implementierungen lassen die Systemzeit des Clients etwas schneller oder etwas langsamer laufen – nach einigen Synchronisationsintervallen bleibt die Zeit so auch nach dem Trennen der Netzwerkverbindung relativ genau.
NTP nimmt an, dass die Zeit für einen Paketaustausch zwischen Server und Client in beide Richtungen dieselbe ist. Die damit erreichbare Genauigkeit ist umstritten – die Angaben reichen von Millisekunden bis Sekunden. Einig ist man sich über die Abhängigkeit der Präzision vom Netztyp. Die aktuelle Version NTPv4 soll die Systemzeit eines Rechners übers Internet mit einer Genauigkeit von 10 Millisekunden halten können, in LANs sollen unter idealen Bedingungen Genauigkeiten von 200 Mikrosekunden erreichbar sein.
Etwas präziser bitte
Wer es präziser haben will, muss zum jüngeren, aber recht unbekannten Precision Time Protocol greifen. PTP ist im Standard IEEE 1588 und in IEC 61588 definiert. Sein Fokus liegt auf der präzisen Synchronisation von Systemen in einem lokalen Netz. Softwareimplementierungen versprechen eine Genauigkeit im Mikro-, Hardwareimplementierungen sogar im Nanosekundenbereich. Der Grund: Im TCP/IP-Stack auftretende Verzögerungen verfälschen das Ergebnis. Diese im Vergleich zu NTP um Größenordnungen bessere Performance erkauft man durch einen höheren Implementierungsaufwand.
PTP verwendet eine hierarchische Master-Slave-Architektur. Anhand des BMC-Algorithmus (Best Master Clock) wählen die Master denjenigen mit der präzisesten Uhr. Diese Grandmaster Clock bildet die Referenzuhr. Das Ermitteln der Zeitdifferenz weist – im Großen und Ganzen – das bekannte Schema auf, allerdings mit ein paar Unterschieden. Zum einen sendet der Master von sich aus zum Bestimmen der Verzögerung (Delay) seine Zeitmarke T1 in Form einer Sync-Message an den Slave. Zum anderen wird zusätzlich T1’ an der Ethernetschnittstelle gemessen und in einem separaten Paket hinterhergeschickt, um die in der Pipeline des Stack zur Hardware auftretende Zeitspanne zu eliminieren. Der Slave hält die Empfangszeit anhand seiner eigenen Zeit als T2 und T2’ fest. Danach sendet er wiederholt Delay Request Messages mit Zeitstempeln T3 an den Master, der die Empfangszeit T4 wiederum als Delay Response Message an den Slave zurücksendet.
Aus den Differenzen der Zeitmarken sind jeweils das Master-to-Slave- und das Slave-to-Master-Delay zu bestimmen. Der Mittelwert beider Größen liefert den gerichteten Offset, also die Zeitabweichung vom Master, die der Slave zur Synchronisation benutzt. PTP schreibt das geregelte Annähern des Slave an die Referenzzeit des Master ohne Zeitsprünge vor.
PTP setzt voraus, dass die Hin- und Rückwege der Synchronisierungsnachrichten je die gleichen mittleren Laufzeiten haben. Zudem verursacht PTP mehr Traffic. Bei NTP sendet der am Systemzeit-Update interessierte Client ein Paket, der Server regiert mit einem weiteren Paket. PTP hingegen belastet das Netz mit den Broadcasts der Master stärker. (sun)