1. Einführung
Wer schon einmal PTP (Precision Time Protocol) unter Linux „klassisch“ mit ptp4l und phc2sys eingerichtet hat, weiß: Das ist mächtig, aber für Anfänger oft recht komplex. Es erfordert mehrere Dienste, abgestimmte Startreihenfolgen, passende Optionen, Profile – und schnell wächst die Zahl der Stellschrauben. Timemaster setzt genau hier an: Es bündelt die Bausteine in einem einfachen, einsteigerfreundlichen Workflow, ohne auf die Präzision von PTP verzichten zu wollen.
Technisch gesehen orchestriert Timemaster ptp4l und phc2sys und verbindet sie mit chronyd oder ntpd, sodass die Systemuhr gleichzeitig PTP- und NTP-Quellen sehen und die jeweils beste Quelle automatisch wählen kann. (Siehe Beschreibung in der Timemaster-Manpage) manpages.debian.org+1
1.1 Warum überhaupt PTP?
Während NTP für viele Anwendungen „ausreichend genau“ ist, spielen die Vorteile von PTP dort eine Rolle, wo es auf Submikrosekunden-Genauigkeit und deterministisches Timing ankommt – etwa in industriellen Netzwerken, im Finanzhandel, bei Audio/Video-Verteilung oder in der Mobilfunktechnik. Mit Hardware-Zeitstempeln am Netzwerkinterface und einer dedizierten PTP Hardware Clock (PHC) lässt sich die Genauigkeit deutlich steigern; phc2sys übernimmt die Synchronisation zwischen PHC und Systemuhr.
Genau diese Kombination, ptp4l + phc2sys, verpackt Timemaster in eine einheitliche Konfiguration, inklusive sauberer Anbindung an chronyd/ntpd als Fallback oder Bewertungsinstanz. Linux PTP Project+2manpages.debian.org+2
1.2 Was macht Timemaster konkret einfacher?
- Beim Start liest Timemaster eine einzige Konfigurationsdatei, in der NTP- und PTP-Quellen definiert sind.
- Es erkennt automatisch, welche Netzwerkinterfaces einen PHC haben oder teilen, und generiert passende Konfigurationen für ptp4l und chronyd/ntpd.
- Es startet, falls nötig, alle Prozesse (ptp4l, phc2sys, chronyd/ntpd) in der richtigen Reihenfolge und kümmert sich beim Beenden um das Aufräumen.
- Die PTP-Zeit wird über SOCK-Refclock (bei chronyd) bzw. SHM-Refclock (bei ntpd) eingespeist, sodass die NTP-/PTP-Instanz alle Quellen bewerten kann und die beste auswählt. manpages.debian.org+1
So entstehen weniger manuelle Konfigurationen und klarere Zuständigkeiten, aber mit der Option, bei Bedarf gezielt in die Details von ptp4l/phc2sys einzugreifen.
1.3 Für wen ist Timemaster gedacht?
Timemaster ist ideal für alle, die PTP einsetzen möchten, aber nicht sofort tief in die Feinheiten von ptp4l/phc2sys einsteigen wollen — etwa für Heim- oder Labornetzwerke, kleine Produktionsumgebungen oder Entwickler, die einfach eine stabile, genaue Systemzeit brauchen.
Auch in komplexeren Setups bringt Timemaster Vorteile: Es unterstützt mehrere PTP-Domänen, kann mehrere Schnittstellen gruppieren und, unter neueren Linux-Kerneln, vclocks (virtuelle Zeituhren) aktivieren, um mehrere ptp4l-Instanzen auf einer PHC zu betreiben (ab Kernel-Version ≧ 5.18). manpages.debian.org+1
1.4 Woher kommt Timemaster – und warum wurde es entwickelt?
Timemaster ist Teil des LinuxPTP-Projekts, das die Referenzimplementierung des Precision Time Protocols für Linux liefert (u. a. ptp4l, phc2sys). Red Hat Dokumentation+3linuxptp.sourceforge.net+3Linux PTP Project+3
Der Zweck von Timemaster ist es, PTP und NTP zusammenzuführen, sodass die Systemzeit gleichzeitig PTP-Refclocks und NTP-Server nutzen kann, mit Orchestrierung und Fallback aus einer Hand. Dabei verzichtet Timemaster nicht auf die Flexibilität — zusätzliche ptp4l- oder phc2sys-Optionen können weiterhin gezielt genutzt werden. Linux PTP Project+1
1.5 Vorteile & Nachteile im Überblick
1.5.1 Vorteile (Pro)
- Einfacherer Einstieg & weniger Einzelkomponenten: Statt vieler kleiner Konfigurationsdateien genügt eine zentrale.
- Sauberes Zusammenspiel von PTP und NTP: chronyd/ntpd sieht PTP als Refclock und kann dynamisch entscheiden, welche Quelle zu verwenden ist.
- Skalierbarkeit & moderne Features: Mehrere PTP-Domänen, virtuelle Uhren (vclocks), Client-Modus je Domain usw.
1.5.2 Nachteile / Abwägungen (Kontra)
- Abstraktionsschicht: Für Spezialprofile oder sehr feines Tuning muss man ggf. in ptp4l/phc2sys-Parameter eintauchen.
- Debugging-Komplexität: Logs und Status müssen ggf. an mehreren Stellen geprüft werden, weil Timemaster die Konfiguration generiert und Prozesse orchestriert.
- Grenzen der Daemonen: chronyd und ntpd haben eigene Polling- und Refclock-Limits, die sich auf das Zusammenspiel mit Timemaster auswirken können.
2. Installation
2.1 Installation der benötigten Pakete
Timemaster ist Teil des LinuxPTP-Pakets. Je nach Distribution heißen die Pakete etwas unterschiedlich:
- Debian / Ubuntu
sudo apt install linuxptp chrony - Red Hat / CentOS / Fedora
sudo dnf install linuxptp chrony - Arch Linux / Manjaro
sudo pacman -S linuxptp chrony - openSUSE
sudo zypper install linuxptp chrony
👉 Wichtig: Du brauchst zusätzlich chrony (oder ntpd, falls du das lieber einsetzt). In den meisten Fällen ist chrony die bessere Wahl.
2.2 Beispielkonfiguration für Timemaster
Die zentrale Datei liegt normalerweise unter/etc/timemaster.conf
Ich habe folgende Beispieldatei erstellt:
[ntp_server ptbtime1.ptb.de] minpoll 3 maxpoll 4 iburst 1 [ntp_server ptbtime2.ptb.de] minpoll 3 maxpoll 4 iburst 1 [ntp_server ptbtime3.ptb.de] minpoll 3 maxpoll 4 iburst 1 [ptp_domain 0] interfaces enp14s0f0 ntp_poll 0 phc2sys_poll -2 delay 10e-6 ntp_options tai pps prefer [timemaster] ntp_program chronyd rundir /var/run/timemaster restart_processes 0 use_vclocks 0 [chronyd] path /usr/sbin/chronyd options [chrony.conf] leapsectz right/UTC makestep 1 3 logchange 0.5 rtcsync driftfile /var/lib/chrony/drift logdir /var/log/chrony [phc2sys] path /usr/sbin/phc2sys options -l 5 [ptp4l] path /usr/sbin/ptp4l options [ptp4l.conf] logging_level 5
2.2.3 Erklärung der wichtigsten Parameter
- [ntp_server]: Externe Zeitserver (hier die PTB in Deutschland). Diese solltest du an deine Region anpassen.
minpoll/maxpoll: Abfrageintervall in 2er-Potenzen (hier ca. alle 8-16 Sekunden).iburst: Schnellere Synchronisation beim Start.
- [ptp_domain]: Definition der PTP-Instanz.
interfaces: Dein Netzwerkinterface mit PTP-Hardware-Clock.ntp_poll: Polling-Intervall für die NTP-Anbindung des PTP.phc2sys_poll: Wie oft phc2sys ausgeführt wird (−2 = sehr häufig).delay: Erwartete Delay-Schätzung.ntp_options tai pps prefer: Übergibt Optionen an chronyd → TAI-Skalierung, PPS nutzen, PTP bevorzugen.
- [timemaster]: Globale Timemaster-Optionen.
ntp_program: NTP-Daemon (hier chronyd).restart_processes: Ob Prozesse automatisch neugestartet werden sollen.use_vclocks: Nutzung virtueller Uhren (0 = aus).
- [chrony.conf]: Zusätzliche Optionen für chronyd, z. B.
makestep,driftfile. - [phc2sys]: Parameter für phc2sys, hier mit Log-Level 5.
- [ptp4l] und [ptp4l.conf]: Parameter für ptp4l, z. B.
logging_level.
👉 Für deine eigene Umgebung musst du vor allem Interface (enp14s0f0) und ggf. die NTP-Server anpassen.
2.3 Erster manueller Test
Zuerst Timemaster nicht als Service starten, sondern manuell aufrufen:
sudo timemaster -n
Option -n hält den Prozess im Vordergrund, sodass du die Logs direkt im Terminal siehst. Damit lässt sich prüfen, ob alle Subprozesse (ptp4l, phc2sys, chronyd) sauber starten.
2.4 Ergebnisse überprüfen
Wenn Timemaster läuft, kannst du mit chronyc die Quellen abfragen:
chronyc sources -v
2.4.1 Beispielausgabe:
.-- Source mode '^' = server, '=' = peer, '#' = local clock. / .- Source state '*' = current best, '+' = combined, '-' = not combined, | / 'x' = may be in error, '~' = too variable, '?' = unusable. || .- xxxx [ yyyy ] +/- zzzz || Reachability register (octal) -. | xxxx = adjusted offset, || Log2(Polling interval) --. | | yyyy = measured offset, || \ | | zzzz = estimated error. || | | \ MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== #* PTP0 0 0 377 1 -55ns[ -282ns] +/- 5084ns ^- ptbtime1.ptb.de 1 3 377 10 -3293us[-3293us] +/- 20ms ^- ptbtime2.ptb.de 1 3 377 9 -3186us[-3186us] +/- 20ms ^- ptbtime3.ptb.de 1 3 377 42 -3110us[-3107us] +/- 20ms
👉 Interpretation:
#* PTP0: PTP ist aktuell die beste Quelle.- Die PTB-Server sind zusätzliche Referenzen, dienen als Fallback.
chronyc sourcestats -v
2.4.2 Hier siehst du statistische Werte (Offset, Jitter, Frequenzabweichungen).
.- Number of sample points in measurement set. / .- Number of residual runs with same sign. | / .- Length of measurement set (time). | | / .- Est. clock freq error (ppm). | | | / .- Est. error in freq. | | | | / .- Est. offset. | | | | | | On the -. | | | | | | samples. \ | | | | | | | Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev ============================================================================== PTP0 6 5 5 +0.013 0.146 +12ns 73ns ptbtime1.ptb.de 9 7 202 -0.616 6.154 -3441us 213us ptbtime2.ptb.de 22 10 338 -0.249 0.995 -3395us 143us ptbtime3.ptb.de 23 13 354 +0.428 0.810 -3254us 125us
👉 Hier sieht man, dass PTP nanosekunden-genau arbeitet, während NTP im Millisekunden-Bereich bleibt.
chronyc tracking
2.4.3 Statusübersicht der Systemzeit:
Reference ID : 50545030 (PTP0) Stratum : 1 Ref time (UTC) : Sat Oct 04 09:08:31 2025 System time : 0.000000274 seconds fast of NTP time Last offset : +0.000000428 seconds RMS offset : 0.000000378 seconds Frequency : 31.444 ppm slow Residual freq : +0.016 ppm Skew : 0.372 ppm Root delay : 0.000010000 seconds Root dispersion : 0.000002222 seconds Update interval : 1.0 seconds Leap status : Normal
👉 Interpretation:
- Reference ID = PTP0 → PTP ist die aktive Quelle.
- Offset im Nanosekunden-Bereich → exakte Synchronisation.
- Stratum 1 → eigene Instanz, direkt mit PTP synchronisiert.
2.5 Timemaster als systemd-Dienst einrichten
Damit Timemaster beim Booten automatisch startet, legen wir einen eigenen systemd-Dienst an.
2.5.1 Service-Datei erstellen
sudo tee /etc/systemd/system/timemaster.service >/dev/null <<'EOF' [Unit] Description=timemaster - orchestrate ptp4l, phc2sys and chronyd/ntpd Documentation=man:timemaster(8) Wants=network-online.target After=network-online.target ConditionPathExists=/etc/timemaster.conf # Verhindert Parallelbetrieb konkurrierender Dienste: Conflicts=chronyd.service ntp.service ntpd.service ptp4l-slave.service phc2sys-slave.service systemd-timesyncd.service # Falls diese gerade laufen, werden sie gestoppt bevor timemaster startet: Before=chronyd.service ntp.service ntpd.service ptp4l-slave.service phc2sys-slave.service systemd-timesyncd.service [Service] Type=simple # Laufzeitverzeichnis /run/timemaster (== /var/run/timemaster) automatisch anlegen RuntimeDirectory=timemaster RuntimeDirectoryMode=0755 # timemaster liest /etc/timemaster.conf und startet/überwacht ptp4l+phc2sys+chronyd/ntpd ExecStart=/usr/bin/timemaster -f /etc/timemaster.conf Restart=on-failure RestartSec=2 # Protokolle ins Journal StandardOutput=journal StandardError=journal [Install] WantedBy=multi-user.target EOF
2.5.2 Dienst aktivieren und starten
sudo systemctl daemon-reload sudo systemctl enable --now timemaster.service sudo systemctl start timemaster.service sudo systemctl status timemaster.service
👉 Damit ist Timemaster als dauerhafter Dienst eingebunden.
2.5.3 Logs prüfen
Die Logs sind besonders nützlich, um zu sehen, ob alle Komponenten (chronyd, ptp4l, phc2sys) sauber gestartet wurden:
journalctl -xeu timemaster
Beispielausgabe (gekürzt):
Okt 04 11:05:13 stargazer timemaster[45842]: process 45846 started: /usr/sbin/chronyd -n -f /var/run/timemaster/chrony.conf Okt 04 11:05:13 stargazer timemaster[45842]: process 45847 started: /usr/sbin/ptp4l -f /var/run/timemaster/ptp4l.0.conf -H -i enp14s0f0 Okt 04 11:05:13 stargazer timemaster[45842]: process 45848 started: /usr/sbin/phc2sys -l 5 -a -r -R 4.00 -z /var/run/timemaster/ptp4l.0.socket Okt 04 11:05:14 stargazer ptp4l[45847]: port 1 (enp14s0f0): new foreign master 2ccf67.fffe.fccc11-1 Okt 04 11:05:18 stargazer chronyd[45846]: Selected source PTP0
👉 Interpretation:
- ptp4l erkennt den Master-Clock im Netzwerk.
- phc2sys synchronisiert die Systemuhr mit der Hardware-Uhr.
- chronyd wählt PTP als Referenzquelle („Selected source PTP0“).
2.5.4 Kontrolle der Synchronisation
Nach Start des Dienstes kannst du wie zuvor beschrieben mit chronyc sources, chronyc sourcestats und chronyc tracking prüfen, ob PTP erfolgreich die führende Quelle ist.
3. Fazit
Mit Timemaster lässt sich die ansonsten recht komplexe Einrichtung von PTP unter Linux erheblich vereinfachen. Anstatt mehrere Dienste wie ptp4l und phc2sys manuell zu starten, Konfigurationsdateien abzustimmen und dafür zu sorgen, dass sie zuverlässig zusammenarbeiten, übernimmt Timemaster diese Aufgaben automatisch.
Gerade für Anfänger ist das ein großer Vorteil: Eine zentrale Konfigurationsdatei reicht aus, um sowohl PTP als auch NTP-Quellen einzubinden. Dadurch wird die Systemzeit hochpräzise mit PTP synchronisiert, während gleichzeitig ein Fallback auf klassische NTP-Server zur Verfügung steht.
Natürlich gibt es auch Grenzen: Wer sehr spezielle PTP-Profile, individuelle Servoparameter oder komplexe Multi-Domain-Setups benötigt, muss weiterhin die Details von ptp4l und phc2sys im Blick behalten. Doch für die meisten Anwender, die verlässliche Genauigkeit im Nanosekundenbereich suchen, ist Timemaster ein idealer Einstieg.
Kurz gesagt:
- Einfacher, schneller und robuster als der direkte Einsatz von ptp4l & phc2sys.
- Flexibel genug, um auch in fortgeschrittenen Umgebungen zu bestehen.
- Damit die perfekte Wahl für alle, die von „kompliziert zu simpel“ wechseln wollen.
