PTP: Precision Time Protocol als NTP-Alternative für Sub-Millisekunden-Genauigkeit

1. Warum NTP für manche Anwendungsfälle nicht ausreicht

NTP synchronisiert Systemuhren über das Internet oder ein lokales Netzwerk hinweg üblicherweise auf einige Millisekunden genau, in gut konfigurierten lokalen Netzwerken mit chrony sogar auf niedrige zweistellige Mikrosekunden. Für die überwiegende Mehrheit administrativer Aufgaben, von Log-Zeitstempeln bis zu TLS-Zertifikatsprüfungen, ist diese Genauigkeit vollkommen ausreichend. Es gibt jedoch Anwendungsklassen, bei denen selbst wenige Mikrosekunden Abweichung geschäftskritisch oder technisch inakzeptabel sind.

Ein Hochfrequenz-Handelssystem muss die exakte Reihenfolge von Marktereignissen über mehrere Server hinweg rekonstruieren können, was Zeitstempel mit Nanosekunden-Genauigkeit voraussetzt. Verteilte Datenbanken mit externer Konsistenz, etwa Systeme, die auf global synchronisierten Zeitstempeln zur Konfliktauflösung setzen, benötigen ebenfalls deutlich engere Zeitfenster als NTP liefern kann. Telekommunikationsnetze, insbesondere 5G-Basisstationen mit Zeitschlitz-Multiplexing, verlangen nach Industriestandards oft eine Genauigkeit im Sub-Mikrosekunden-Bereich zwischen benachbarten Netzelementen.

Genau für diese Fälle existiert PTP, das Precision Time Protocol nach IEEE 1588. Während NTP auf Software-Zeitstempeln basiert, die durch Betriebssystem-Latenzen und Netzwerk-Stack-Verzögerungen unweigerlich verrauscht sind, nutzt PTP Hardware-Timestamping direkt in der Netzwerkkarte, wodurch ein Großteil dieser Unsicherheitsquellen entfällt. Der Unterschied zwischen NTP und PTP ist also weniger ein Unterschied im Algorithmus als ein Unterschied darin, wo im Netzwerkstack der Zeitstempel tatsächlich erzeugt wird.

2. Wie PTP funktioniert: Hardware-Timestamping und Boundary Clocks

Der fundamentale Unterschied zwischen NTP und PTP liegt im Ort der Zeitstempel-Erzeugung. Bei NTP entsteht der Zeitstempel für ein ausgehendes Paket in der Anwendung oder im Betriebssystem-Kernel, lange bevor das Paket tatsächlich die physische Netzwerkkarte verlässt. Diese Verzögerung zwischen Zeitstempel-Erzeugung und tatsächlichem Versand ist variabel und abhängig von der aktuellen Systemlast, was eine nicht zu eliminierende Unsicherheit in die Messung einbringt. PTP verlagert die Zeitstempel-Erzeugung direkt in die Netzwerkkarten-Hardware, an den Punkt, an dem das Paket physisch das Medium verlässt beziehungsweise erreicht, wodurch Betriebssystem-Jitter komplett aus der Messung herausfällt.

Eine PTP-Domain organisiert sich in einer Hierarchie: Eine Grandmaster Clock, meist an eine GNSS-Antenne wie GPS angebunden, bildet die Zeitquelle höchster Genauigkeit. Boundary Clocks, typischerweise in Netzwerk-Switches integriert, synchronisieren sich mit der Grandmaster Clock und geben die Zeit an nachgeordnete Segmente weiter, wodurch Genauigkeitsverluste über mehrere Netzwerk-Hops hinweg minimiert werden. Endgeräte, sogenannte Ordinary Clocks, synchronisieren sich schließlich mit der nächstgelegenen Boundary Clock oder direkt mit der Grandmaster Clock, falls kein PTP-fähiger Switch dazwischenliegt.

Der Nachrichtenaustausch selbst folgt einem Vier-Wege-Handshake namens Delay Request Response Mechanism: Sync- und Follow-Up-Nachrichten fließen von Master zu Slave, Delay-Request- und Delay-Response-Nachrichten fließen zurück, wodurch beide Richtungen der Netzwerklaufzeit gemessen und der Offset zwischen beiden Uhren präzise berechnet werden kann. Diese symmetrische Messung setzt allerdings voraus, dass Hin- und Rückweg tatsächlich ähnliche Laufzeiten haben, eine Annahme, die in asymmetrischen Netzwerktopologien zu zusätzlichen Fehlerquellen führen kann.

3. linuxptp installieren: ptp4l und phc2sys

Die Referenzimplementierung von PTP unter Linux heißt linuxptp und besteht im Kern aus zwei Programmen: ptp4l synchronisiert die Hardware-Uhr der Netzwerkkarte, die sogenannte PTP Hardware Clock, mit dem PTP-Netzwerk, während phc2sys anschließend diese Hardware-Uhr mit der Systemuhr des Betriebssystems abgleicht. Diese Trennung in zwei Schritte ist bewusst so gestaltet, da nicht jede Netzwerkkarte über eine eigene Hardware-Uhr verfügt und Software-Timestamping als Fallback ebenfalls unterstützt wird, wenn auch mit geringerer Genauigkeit.

Die Installation erfolgt auf den meisten Debian- und Ubuntu-Systemen über den Paketmanager, RHEL-basierte Systeme führen das Paket unter demselben Namen. Nach der Installation ist eine erste Prüfung der Netzwerkkarten-Fähigkeiten unerlässlich, da Hardware-Timestamping nicht von jeder Netzwerkkarte unterstützt wird, dazu mehr im folgenden Abschnitt.

#!/usr/bin/env bash
# Install linuxptp and verify the binaries are available
set -euo pipefail

apt-get update -qq
apt-get install -y linuxptp

# Confirm both core binaries are present
which ptp4l
which phc2sys

ptp4l --version

4. Eine PTP-Domain im lokalen Netzwerk konfigurieren

Die Konfiguration von ptp4l erfolgt über eine Konfigurationsdatei, üblicherweise /etc/linuxptp/ptp4l.conf, in der globale Einstellungen sowie pro-Interface-Einstellungen definiert werden. Die wichtigsten globalen Parameter sind die PTP-Domain-Nummer, die mehrere unabhängige PTP-Netzwerke auf demselben physischen Netz voneinander trennt, sowie das Transport-Protokoll, wobei UDPv4 für die meisten Standard-Ethernet-Netzwerke die gängige Wahl ist, während Layer-2-Transport in spezialisierten Industrienetzwerken verbreitet ist.

Für ein einfaches lokales Setup mit einem Server als Grandmaster Clock und weiteren Servern als Slaves genügt eine identische Konfigurationsdatei auf allen Beteiligten, da ptp4l über den Best Master Clock Algorithmus automatisch aushandelt, welche der beteiligten Uhren als Master fungiert, basierend auf konfigurierbaren Prioritäts- und Qualitätswerten. Ein Server mit einer an GPS angebundenen Uhr sollte über eine niedrigere priority1-Zahl bevorzugt als Master gewählt werden, da niedrigere Werte im Best Master Clock Algorithmus eine höhere Priorität bedeuten.

# /etc/linuxptp/ptp4l.conf — minimal single-domain configuration
[global]
domainNumber          0
priority1             128
priority2             128
# Lower priority1 value wins the Best Master Clock election
# A GPS-disciplined server would use e.g. priority1 = 10

# Prefer hardware timestamping when the NIC supports it
time_stamping         hardware

# Standard transport for typical Ethernet networks
network_transport     UDPv4

[eth0]
# Interface-specific overrides go under a section named after the NIC

5. Hardware-Timestamping: Netzwerkkarten-Voraussetzungen prüfen

Nicht jede Netzwerkkarte unterstützt Hardware-Timestamping, und ohne diese Unterstützung verliert PTP einen Großteil seines Genauigkeitsvorteils gegenüber NTP. Der Befehl ethtool -T interface zeigt an, welche Timestamping-Modi eine Netzwerkkarte unterstützt: HWTSTAMP_TX_ON und HWTSTAMP_FILTER_PTP_V2_L4_EVENT in der Ausgabe deuten auf funktionierendes Hardware-Timestamping für PTP-Pakete hin. Server-Netzwerkkarten von Intel, insbesondere die 82599- und X710-Serien, sowie viele Broadcom-Chipsätze in Rechenzentrums-Hardware unterstützen diese Funktion standardmäßig, während günstige Consumer-Netzwerkkarten sie häufig gar nicht implementieren.

Fehlt Hardware-Timestamping, fällt ptp4l automatisch auf Software-Timestamping zurück, was PTP zwar weiterhin funktionsfähig, aber deutlich weniger präzise macht, in der Praxis oft nicht wesentlich besser als eine gut konfigurierte NTP-Installation mit chrony. Für Umgebungen, in denen die Sub-Mikrosekunden-Genauigkeit tatsächlich benötigt wird, ist eine vorherige Prüfung der Netzwerkkarten-Kompatibilität deshalb der wichtigste erste Schritt, noch vor der eigentlichen ptp4l-Konfiguration.

#!/usr/bin/env bash
# Check whether a network interface supports PTP hardware timestamping
set -euo pipefail

readonly IFACE="eth0"

# Look for hardware timestamping capability flags
ethtool -T "$IFACE"

# Expected relevant lines in the output:
# Hardware Transmit Timestamp Modes:
#     off
#     on
# Hardware Receive Filter Modes:
#     none
#     ptpv2-event
#     ptpv2-l4-event

# If only "off" and "none" appear, the NIC lacks hardware timestamping
# support, and ptp4l will fall back to less precise software timestamping.

6. phc2sys: PTP-Hardware-Clock mit der Systemuhr synchronisieren

ptp4l synchronisiert ausschließlich die PTP Hardware Clock der Netzwerkkarte selbst, nicht die Systemuhr des Betriebssystems, die weiterhin von Anwendungen über clock_gettime abgefragt wird. phc2sys übernimmt genau diesen zweiten Schritt: Es liest kontinuierlich die PTP Hardware Clock aus und passt die Systemuhr entsprechend an, entweder über sanftes Anpassen der Systemuhr-Frequenz oder, bei größeren initialen Abweichungen, über einen einmaligen Zeitsprung beim Start.

Der Aufruf von phc2sys erfordert die explizite Angabe, welche Hardware-Uhr als Quelle und welche als Ziel dient, üblicherweise die PTP Hardware Clock der Netzwerkkarte als Quelle und CLOCK_REALTIME, also die Systemuhr, als Ziel. In produktiven Umgebungen läuft phc2sys als eigener systemd-Dienst parallel zu ptp4l, wobei beide Dienste über die systemd-Unit-Dateien des linuxptp-Pakets bereits vorkonfiguriert sind und lediglich an die tatsächlich verwendete Netzwerkkarte angepasst werden müssen.

#!/usr/bin/env bash
# Start ptp4l and phc2sys together, syncing hardware clock to system clock
set -euo pipefail

readonly IFACE="eth0"

# Start ptp4l in the background, syncing the NIC's PTP hardware clock
ptp4l -i "$IFACE" -f /etc/linuxptp/ptp4l.conf -m &

# Wait briefly for ptp4l to establish a session with the master
sleep 5

# Sync the system clock (CLOCK_REALTIME) from the PTP hardware clock
phc2sys -s "$IFACE" -c CLOCK_REALTIME -w -m &

# Both should ideally run as systemd services in production:
# systemctl enable --now ptp4l phc2sys

7. PTP überwachen: das pmc-Tool und Offset-Werte

Die Überwachung einer laufenden PTP-Synchronisation erfolgt über das mitgelieferte pmc-Kommando, den PTP Management Client, der Anfragen an den laufenden ptp4l-Prozess über den Management-Nachrichtenkanal des Protokolls sendet. Der wichtigste abzufragende Wert ist der aktuelle Offset zur Master Clock, ausgegeben in Nanosekunden, sowie die aktuelle Rolle der lokalen Uhr innerhalb der PTP-Hierarchie, also ob sie als Master oder Slave agiert.

Ein stabiles PTP-Setup mit funktionierendem Hardware-Timestamping sollte einen Offset im niedrigen dreistelligen Nanosekunden-Bereich oder darunter zeigen, während wachsende oder stark schwankende Offset-Werte auf Netzwerkprobleme, fehlende Hardware-Timestamping-Unterstützung oder eine überlastete Grandmaster Clock hindeuten. Zusätzlich zum manuellen pmc-Abfragen lohnt sich für den Dauerbetrieb die Integration der Offset-Werte in ein Monitoring-System wie Prometheus, um langfristige Trends und Ausreißer automatisch zu erkennen, statt sie nur bei manueller Prüfung zu bemerken.

#!/usr/bin/env bash
# Query PTP synchronization status via the pmc management client
set -euo pipefail

# Current offset from master, in nanoseconds
pmc -u -b 0 'GET CURRENT_DATA_SET'

# Expected output includes a line like:
# offsetFromMaster       45
# meanPathDelay          612

# Query the local clock's role: MASTER, SLAVE, or PASSIVE
pmc -u -b 0 'GET PORT_DATA_SET' | grep -i "portState"

# Continuous monitoring loop for a health dashboard
while true; do
  offset="$(pmc -u -b 0 'GET CURRENT_DATA_SET' | grep offsetFromMaster | awk '{print $2}')"
  echo "$(date -u +%FT%TZ) offset_ns=${offset}"
  sleep 5
done

8. Typische Einsatzszenarien für PTP

Finanzhandelssysteme gehören zu den bekanntesten Einsatzgebieten von PTP, da Regulierungsvorschriften wie MiFID II in der EU explizit Zeitstempel-Genauigkeiten im Mikrosekundenbereich für Hochfrequenz-Handelsplätze vorschreiben, um die exakte Reihenfolge von Transaktionen über mehrere Server hinweg rechtlich nachvollziehbar zu dokumentieren. Ohne PTP-Niveau-Genauigkeit lässt sich die Reihenfolge zweier Ereignisse, die innerhalb weniger Mikrosekunden auf unterschiedlichen Servern stattfinden, schlicht nicht zuverlässig rekonstruieren.

Verteilte Datenbanksysteme mit globaler Konsistenzgarantie, die auf synchronisierten Zeitstempeln zur Konfliktauflösung zwischen gleichzeitigen Schreibvorgängen setzen, profitieren ebenfalls erheblich von PTP-Niveau-Genauigkeit, da ein zu großes Zeitfenster zwischen Servern zu inkorrekten Konfliktentscheidungen führen kann. Im Telekommunikationsbereich verlangen 5G-Basisstationen mit Zeitschlitz-basiertem Multiplexing zwischen benachbarten Funkzellen eine enge Zeitsynchronisation, um Interferenzen an Zellgrenzen zu vermeiden, weshalb PTP-Profile wie ITU-T G.8275.1 speziell für Mobilfunknetze standardisiert wurden.

Für die überwiegende Mehrheit von Webanwendungen, Magento-Shops und klassischen Datenbank-Setups ist diese Genauigkeitsklasse jedoch weit über den tatsächlichen Bedarf hinaus, weshalb PTP für Standard-Hosting-Umgebungen selten die richtige Wahl ist. Eine gut konfigurierte chrony-Installation deckt die praktischen Anforderungen dieser Anwendungen vollständig ab, ohne den zusätzlichen Hardware- und Konfigurationsaufwand von PTP zu benötigen.

9. NTP vs. chrony vs. PTP im Vergleich

Die folgende Tabelle stellt die drei gängigsten Zeitsynchronisationsansätze unter Linux gegenüber, um die passende Wahl je nach Genauigkeitsanforderung zu erleichtern.

Als Faustregel gilt: chrony ist für praktisch jede administrative und webbasierte Anwendung die richtige Wahl. PTP lohnt sich ausschließlich dann, wenn eine konkrete regulatorische Vorgabe oder eine technische Notwendigkeit im Mikrosekunden- oder Nanosekunden-Bereich besteht und die nötige PTP-fähige Netzwerkhardware bereits vorhanden ist oder budgetiert werden kann.

10. Zusammenfassung

PTP nach IEEE 1588 erreicht Sub-Mikrosekunden- bis Nanosekunden-Genauigkeit, indem es Zeitstempel direkt in der Netzwerkkarten-Hardware erzeugt, statt sich auf Software-Zeitstempel im Betriebssystem-Stack zu verlassen, wie es NTP tut. ptp4l synchronisiert die PTP Hardware Clock der Netzwerkkarte mit dem PTP-Netzwerk, phc2sys übernimmt den zweiten Schritt und gleicht die Systemuhr mit dieser Hardware-Uhr ab. Hardware-Timestamping-Unterstützung der Netzwerkkarte ist dabei zwingende Voraussetzung für den vollen Genauigkeitsgewinn.

Typische Einsatzgebiete sind Finanzhandelssysteme mit regulatorischen Zeitstempel-Anforderungen, verteilte Datenbanken mit globaler Konsistenzgarantie und Telekommunikationsnetze mit Zeitschlitz-Multiplexing. Für die überwiegende Mehrheit von Webanwendungen und Standard-Server-Betrieb bleibt chrony die richtige, deutlich einfacher zu betreibende Wahl, PTP lohnt sich nur bei konkretem Mikrosekunden- oder Nanosekunden-Bedarf.

11. FAQ: PTP unter Linux