© psdesign1, Fotolia

Wenn Linux anhand des Precision Time Protocol an der Uhr dreht, schmilzt der Gangfehler zwischen zwei synchronisierten Geräten mindestens auf den millionsten Teil vom Flügelschlag eines Kolibris. Welcher Code für die viele Pünktlichkeit sorgt und wozu das gut ist, erklärt die Kern-Technik.

Dass sich die (Uhr)-Zeitgeber unserer PCs, Server, Router, Smartphones und Tablets ab und zu über das Internet versichern, korrekt zu laufen und nötigenfalls ein paar Ticks nachjustieren, ist Stand der Technik: Sie kontaktieren per Network Time Protocol (NTP) einfach einen Zeitserver und holen dessen Zeit ab. Ein ausgefeilter Mechanismus rechnet dabei Paketlaufzeiten heraus und passt die Ganggeschwindigkeit (Frequenz) des eigenen Uhrwerks auf die des Zeitservers an. Unter günstigen Umständen läuft das eigene System millisekundengenau synchron zum Zeitserver.

Das ganze ist keine technikverliebte Spielerei, denn differieren die Uhren miteinander arbeitender Systeme, dann verlieren Zeitstempel, die zusammen mit Daten, Messwerten oder Ereignissen erzeugt werden, ihre Aussagekraft. Kein System könnte mehr über eine Ereignisreihenfolge eine zuverlässige Auskunft geben.

Das gilt für alle verteilten Systeme, sei es in der Automatisierungstechnik, wo kooperativ arbeitende Maschinen und Roboter schnell laufende Antriebe koordinieren, sei es in Autos, wo Steuergeräte in korrekter Reihenfolge Aktionen auszuführen haben, bei übers Land verschalteten Kraftwerksanlagen oder in jeder zentral protokollierten Serverlandschaft. Selbst bei Finanztransaktionen kommt es auf die zehntausendstel Sekunde an: So fordert beispielsweise die neueste Richtlinie MiFID 2, die am 1. Januar 2018 in Kraft treten wird [1], für die Zeitgeber-Synchronisation eine Genauigkeit von mindestens 100 Mikrosekunden. Mit NTP ist diese Genauigkeit in der Praxis nur unter ungewöhnlich günstigsten Umständen zu erreichen [2].

Da geht doch mehr

Eine deutlich genauere Synchronisation als das Network Time Protocol verspricht das Precision Time Protocol (PTP, [3]), das als IEEE 1588/2002 und IEEE 1588/2008 normiert ist. Hiermit lassen sich Genauigkeiten bis hinunter zu einigen Nanosekunden erreichen. Nicht zwingend vorgeschrieben, aber einer Präzision im einstelligen Mikrosekundenbereich zuträglich ist, wenn die zu synchronisierenden Geräte demselben lokalen Netz angehören und die verwendeten Ethernetkarten eine dedizierte PTP-Hardwareunterstützung aufweisen.

PTP ist ein Master-Slave-Protokoll, bei dem die Slaves ihre Zeitgeber nach dem des Master synchronisieren. In der PTP-Welt können Geräte aber auch Master und Slave zugleich sein (Abbildung 1). In diesem Fall spricht man von einer Boundary Clock. Ein Switch oder ein Router beispielsweise, der mehrere Ethernetstränge verbindet, übernimmt diese Rolle. Zu den Slaves hin ist er der Master. Er selbst ist aber auch Slave zum so genannten Grandmaster, dem Rechner, der seine genaue Uhrzeit beispielsweise per GPS oder als DCF77-Signal aus Braunschweig (die Langwellen-Sendemasten stehen in Mainflingen bei Frankfurt) bezieht und nur die Master-Rolle inne hat.

Per PTP gleichen die Slaves nun ihre Zeit mit dem Master ab. Wie im Kasten “Die Abläufe beim PTP” dargestellt, sind nur wenige Pakete auszutauschen und die exakten Absende- und Ankunftszeitpunkte der Pakete zu protokollieren. Etwas Mathematik berechnet daraus den zeitlichen Offset zwischen Master und Slave.

Aber PTP bietet mehr als nur abgeglichene Uhrzeiten. Es sorgt auch dafür, dass Frequenz und Phase aller beim PTP mitwirkenden Zeitgeber in Einklang kommen: Die Frequenz, damit die Zeitgeber exakt gleich schnell laufen, und Phase, damit die Zeitpunkte, an denen alle Zeitgeber ihre Tickersignale abgegeben, genau gleich sind. Dazu modifiziert jeder Slave auf Basis der zum Master gemessenen Abweichungen sorgfältig die Frequenz seines Taktgebers. Das ist nicht trivial und bedarf neben der Kernelunterstützung einer Menge Regelungstechnik, die letztlich die Implementierung des Protokolls kompliziert macht.

Ungenauigkeiten beim Zeitabgleich per PTP ergeben sich aus den Schwankungen bei der Datenübertragung und dem zeitlichen Versatz zwischen dem Nehmen des Zeitstempels und dem Versenden eines Datenpakets. Das letzte Problem minimiert sich, wenn die Netzwerkkarte selbsttätig den Zeitstempel beim Versenden und beim Empfang erfasst.

Ethernet-Hardware, die dieses Feature bietet, hat einen extra Zeitgeber und klassischerweise einen programierbaren Frequenzgenerator an Board. In diesem Fall synchronisiert der Zeitgeber der Netzwerkkarte sich mit dem Zeitgeber des Master. Da das Betriebssystem – Linux beispielsweise – aber nicht mit dem Takt der Netzwerkkarte, sondern seinem eigenen schlägt, synchronisiert sich der Zeitgeber des Betriebssystems noch mit dem Zeitgeber der Netzwerkkarte.

Abbildung 1: Das Precision Time Protocol unterscheidet Grandmaster-, Boundary- und Slave-Clock.

Die Abläufe beim PTP

PTP ist ein Master-Slave-Protokoll, um Uhren (Zeitgeber) in vernetzten Geräten mit extrem hoher Genauigkeit zu synchronisieren. Ein Gerät, der Master, übernimmt dabei die Rolle des Zeitservers, auf den sich die anderen Geräte, die Slaves, synchronisieren. Zeitserver sollte das Gerät sein, dessen Uhr am genauesten geht. Es automatisiert zu identifizieren, gelingt mit einem Mechanismus, der “Best Master Clock”-Algorithmus (BMCA, [4]) heißt.

Abbildung 2 zeigt die Abläufe bei der Zeitsynchronisation nach dem E2E-Verfahren: Der Master schickt dem Client eine Sync-Nachricht, deren Inhalt der Absendezeitpunkt (»t_1«) von ebendieser Nachricht ist. Der Slave merkt sich den Empfangszeitpunkt (»t_2«) dieser Nachricht. Die Zeitdifferenz zwischen den beiden Zeistempeln »t_2« und »t_1« enthält zum einen den Zeitunterschied zwischen den Uhren der beiden Geräte (Offset), die Laufzeit der Datenübertragung und die Laufzeit im Kernel (die in der Software zwischen “Zeitstempel nehmen” und Nachrichtenversand).

Abbildung 2: Den Offset erhält man mit vier Paketen und ein bisschen Mathematik.

Ob die Datenübertragung und -verarbeitung kurz oder lang dauert, ist nicht von Bedeutung, wohl aber, dass die Zeit möglichst konstant ausfällt. Um die Summe der Laufzeiten herauszurechnen, antwortet der Slave dem Zeitserver mit einem so genannten Delay-Request-Paket. Der Client merkt sich dabei den Absendezeitpunkt, »t_3«. Der Zeitserver seinerseits speichert den Empfangszeitpunkt des Paketes, »t_4«, und schickt ihn in einem Delay-Response-Paket an den Client.

Zumeist kommt zu den drei erwähnten Paketen noch ein viertes hinzu, das Follow-up-Paket. Ist es nämlich aus technischen Gründen nicht möglich, den Sendezeitpunkt im Sync-Paket direkt mitzuschicken, schickt der Master den korrekten Sync-Paket-Zeitstempel einfach in dem Follow-up-Paket nach (Abbildung 6).

Aus den beiden Zeitstempeln »t_4« und »t_3« berechnet sich abermals eine Zeitdifferenz, die sich aus dem Offset der beiden Uhren und den Laufzeiten für die Übertragung und durch die Software ergibt. Da die Übertragungsrichtung des Paketes umgekehrt ist, geht der Offset jetzt mit negativem Vorzeichen ein. Mit etwas Mathematik ergibt sich aus den vier Zeitstempeln der Offset zwischen den Uhren (Abbildung 3).

Abbildung 3: PTPv2 verwendet Multicasts zum Austausch der Zeitstempel.

Geschickt ranschleichen ans Ziel

Der geschilderte Zeitvergleich nach dem End-to-End-Verfahren findet mehrmals pro Sekunde statt. Mit jedem Abgleich setzt der Client aber nicht plump die Uhr seiner Netzwerkkarte – oder, wenn die Netzwerkkarte PTP nicht unterstützt, seine Systemuhr – neu. Vielmehr passt das System die Frequenz seines Zeitgebers so an, dass die Uhren nach möglichst kurzer Zeit in absolutem Gleichklang laufen.

Das Ziel ist nicht nur, dass die Clientuhr die gleiche Zeit anzeigt wie die des Masters, sondern sowohl exakt gleich schnell läuft (mit gleicher Frequenz) als auch zur gleichen Zeit weiterschaltet (mit gleicher Phase). Die Anpassung passiert mit klassischer Regelungstechnik, mit der sich der interessierte Systemadministrator überraschenderweise auseinandersetzen muss.

Linux auf der Höhe der Zeit

Die Vokabeln Zeitgeber-Synchronisation und Zeitgeber-Hardware deuten es schon an: Ohne Kernelunterstützung ist PTP nur schwer vorstellbar. Folgerichtig besitzt der Linux-Kernel ein PTP-Subsystem, das dessen Entwickler als Modul »ptp« implementiert haben. Über drei Schnittstellen bietet es seine Dienste an: Eine zur Anwendung, eine zur Netzwerkkarten-Hardware und eine im Sys-Filesystem (siehe Abbildung 4).

Abbildung 4: Das PTP-Subsystem des Kernels implementiert drei Schnittstellen.

Die Anwendung greift über die Socket-Schnittstelle auf die Funktionen des PTP zurück (»SO_TIMESTAMPING«-Option), auch gibt es IO-Controls für den Zugriff auf die PTP-Hardwareclock ([5], [6]).

Damit sich der Treiber der Ethernetkarte in das PTP-Subsystem einklinken kann, haben die Kernelmacher das Objekt »struct ptp_clock_info« in der Headerdatei »ptp_clock_kernel.h« implementiert. Ein Treiberentwickler mit PTP-Ambition instanziert ein solches Objekt, das er per »ptp_clock_register()« dem Kernel übergibt. Um sich vom PTP-Subsystem abzumelden, ruft er »ptp_clock_unregister()« auf. Außerdem schreibt er Funktionen, welche die Frequenz der PTP-Uhr justieren, stellen und auslesen kann.

Das Sys-Filesystem wiederum gibt dem Admin direkten Zugriff auf sämtliche Parameter der Uhrenhardware in der Netzwerkkarte [7], die im Technikerjargon PHC – Physical Clock – heißt. Das Linux-Filesystem spiegelt die Kernelinformationen zu PTP unterhalb von »/sys/class/ptp/« wider (siehe Tabelle 1) – allerdings nur, wenn der Kernel Hardware vorfindet, die er unterstützt.

Linuxptp- oder Ptpd-Praxis

Um in den Genuss von PTP zu kommen, installiert der Admin das Paket Linuxptp. In Ubuntu 16.04 beispielsweise ist das schnell erledigt:

sudo apt-get install linuxptp

Alternativ kann er die Software selbst kompilieren. Dazu holt er die Datei »linuxptp-1.8.tgz« von [8] und packt sie aus (Listing 1). Der Quellcode hat sich im Test als handzahm herausgestellt und ließ sich auf diversen Plattformen wie im Listing gezeigt kompilieren, in »/usr/local/bin/« installieren und schließlich ausführen. Beim Übersetzen entstehen drei ausführbare Programme: »ptp4l«, »phc2sys« und »timemaster«[9].

Alternativ zu Linuxptp haben Debian-basierte Systeme auch das Paket »ptpd« im Angebot, das allerdings keine Hardwareunterstützung bietet und im großen und ganzen ungepflegt wirkt. Versuche des Linuxptp-Autors Cochran, mit dem Ptpd-Projekt zu kooperieren, waren offenbar nicht von Erfolg gekrönt.

Vor dem Start der zentralen Software »ptp4l« steht der Check, ob das eigene System eine PTP-Hardwareunterstützung bietet. Dabei hilft das Programm »ethtool« mit der Option »-T« und unter Angabe des Netzwerkinterfaces. Abbildung 5 zeigt die Ausgabe, falls die Netzwerkkarte keine PTP-Hardware-Uhr hat (»none«). Ist eine Uhr vorhanden, präsentiert »ethtool -T« die Nummer (beginnend bei null). Dann findet sich im System auch eine passende Gerätedatei mit dem Namen »/dev/ptpNummer«. Besitzt die Netzwerkkarte eine Hardware-Uhr, listet »ethtool« außerdem die Funktionen auf, die sie bereitstellt (Abbildung 6).

01 wget https://vorboss.dl.sourceforge.net/project/linuxptp/v1.8/linuxptp-1.8.tgz
02 tar xvf linuxptp-1.8
03 cd linuxptp-1.8
04 make
05 sudo make install

Abbildung 5: Hier arbeitet eine Netzwerkkarte, die kein PTP unterstützt.

Abbildung 6: Die Netzwerkkarte vom Typ E1000 dagegen kann zu PTP in Linux einiges beitragen.

Jetzt wird es Zeit

Die zentrale Softwarekomponente ist das Programm »ptp4l«. Sie führt regelmäßig einen Zeitabgleich durch und passt den Zeitgeber auf die zentrale Uhrzeit an. Als Master startet es beispielsweise mit:

sudo ptp4l -q -l 7 -i eno1 -m

Die Option »-l 7« dient dem neugierigen Admin als Debughilfe, weil die das Loglevel auf 7 anhebt. Die Option »-m« sorgt dafür, dass die Ausgaben auch auf dem Bildschirm landen. Die Ausgabe im Syslog – das wäre der Standard – unterbindet »-q«. Diese Option schützt vor einem allzu schnellen Überlaufen des Syslogs während der Testphase.

Die Option »-i« spezifiziert das Interface, beim Master »eno1«. Auf Systemen mit älteren Kerneln lautet das Interface dagegen »eth0«. Die Änderung der Netzwerk-interfaces haben die Entwicklern übrigens vorgenommen, um eine feste Zuordnung zwischen physischer Netzwerkkarte (beziehungsweise Netzwerkport) und dem logischen Namen zu erlangen. Daher enthalten die modernen Namen jetzt physische Parameter, wie beispielsweise die Slotnummer.

Sobald der Master aktiviert ist, schickt er regelmäßig Announce-, Sync- und Followup-Nachrichten als Multicasts. Falls der Master keine Hardwareunterstützung für PTP mitbringt, fügt der Benutzer die Option für Software-Zeitstempel, »-S«, hinzu. Dann verwendet das System für den Zeitabgleich den zentralen Linux-Systemzeitgeber direkt.

Falls die Hardware der Netzwerkkarte jedoch IEEE-1588-konform ausgeführt ist, muss der Benutzer in einem zusätzlichen Schritt den PTP-Zeitgeber der Netzwerkkarte (Physical Hardware Clock, PHC) mit dem Systemzeitgeber abgleichen. Das gelingt mit dem Programm Phc2sys, dessen Aufrufsyntax etwa die folgende ist:

sudo phc2sys -w -m -q -l 6 -s /dev/ptp0

Die Option »-w« lässt Phc2sys so lange warten, bis sich die Uhr des Slave mit der Masteruhr synchronisiert hat. »-m -q -l 6« sorgen dafür, dass der Admin in der Testphase mehr Informationen erhält, ohne dabei das Syslog zu fluten, und »-s /dev/ptp0« spezifiziert den PTP-Zeitgeber.

Der Slave schließlich startet auf beispielsweise folgende Weise:

sudo ptp4l -A -S -i eth0 -s -l 6 -m -q

Das »-A« erlaubt der Software, das Verfahren zur Zeitberechnung zu wählen. Alternativ zu dem hier beschriebenen und im Normalfall eingesetzten End-to-End-Verfahren (E2E) steht noch Peer to Peer (P2P) zur Verfügung. Letzteres wird der Admin in einem Netzwerk wählen, in dem alle Geräte PTP-fähig sind – insbesondere Switches und Router. Die Option »-S« teilt Ptp4l das Fehlen einer Hardwareclock mit; »-s« schaltet den Slave-Modus ein. Die übrigen Optionen gleichen den beim Master-Aufruf für das Mitprotokollieren. Falls der Slave-Hardware-PTP unterstützt, muss auch hier der Dienst »phc2sys« die System- und die PTP-Uhr synchronisieren.

Das Gespann Ptp4l und Phc2sys synchronisiert hochgenau, wenn sich die Boundary-Clock oder sogar die Grandmaster-Clock im selben Netz befinden. Was aber, wenn es stark schwankende Verzögerungen bei der Datenübertragung selbst gibt, zum Beispiel, weil das Netzwerk überlastet oder aber der nächste Zeitmaster ein paar Hops entfernt ist? Um diesen Fall kümmert sich eine dritte Software, der Timemaster, auch sie ist ein Teil von Linuxptp. Sie evaluiert gemäß der in »/etc/« abgelegten Konfiguration die Zeitquellen und wählt daraus die akkurateste Quelle aus. Dazu aktiviert »timemaster« entweder den Ntpd oder Ptp4l im Gespann mit Phc2sys.

Eine Zeitenwende

Verteilte Anwendungen, für die zeitlich hochgenau aufeinander abgestimmte Rechner essenziell sind, werden mehr. Dieser Tatsache durch Implementierung des Precision Time Protocol gerecht zu werden, war für Linux nur eine Frage der Zeit. Und tatsächlich: PTP für Linux wird den neuen Anforderungen auch dank der Kernelunterstützung gerecht.

Informieren müssen sich Anwender und Programmierer über den neuen Synchronisationsidenst schon. Denn einerseits vereinfacht der Timemaster den Umgang mit unterschiedlichen Zeitquellen und das Aktualisieren der lokalen Zeitgeber prinzipiell, das Zeitmanagement selbst wird anderersits komplexer. (jk)