GPS-gestützter Zeitserver mit Raspberry Pi: So baust Du Deine eigene Grandmaster Clock

1. Einleitung

Präzise Zeit ist heute weit mehr als nur eine Komfortfunktion: Ob in Rechenzentren, bei Finanztransaktionen, in VoIP-Telefonanlagen, beim Logging von Ereignissen oder in der Industrie, exakte Zeitsynchronisation ist die Basis für stabile Abläufe und nachvollziehbare Daten. Professionelle Grandmaster Clocks, die GPS als Referenzquelle nutzen, sind allerdings oft sehr teuer. Dabei lässt sich ein solches System auch im eigenen Netzwerk mit überschaubarem Budget realisieren.

Ein Raspberry Pi in Kombination mit einem GPS-Empfänger und PPS (Pulse Per Second)-Signal eignet sich hervorragend als Grundlage für einen Stratum-1 Zeitserver. Über NTP (Network Time Protocol) oder noch genauer mit PTP (Precision Time Protocol) kann diese Referenzzeit anschließend im lokalen Netz verteilt werden. Damit erhält man eine Lösung, die nicht nur im Hobby- oder Laboreinsatz überzeugt, sondern auch für kleinere Firmenumgebungen interessant ist.

In diesem Beitrag erfährst Du Schritt für Schritt, wie Du mit einem Raspberry Pi eine eigene GPS-gestützte Grandmaster Clock aufbaust, welche Hardware erforderlich ist, welche Softwarelösungen (z. B. Chrony oder ptpd) sich eignen und wie die Konfiguration erfolgt, um im Heimnetz oder im Rechenzentrum hochpräzise Zeit bereitzustellen.

2. Voraussetzungen für den Bau einer GPS Grandmaster Clock mit Raspberry Pi

Um einen Raspberry Pi in eine präzise Grandmaster Clock zu verwandeln, braucht es einige grundlegende Komponenten und die richtige Auswahl der Hardware:

1. Raspberry Pi
   • Grundsätzlich funktioniert fast jedes Modell ab Raspberry Pi 3 als Stratum-1-Zeitserver über NTP.
   • Für Hardware-PTP (Precision Time Protocol, IEEE 1588) ist jedoch mindestens ein Raspberry Pi 4 oder neuer erforderlich, da erst hier die Netzwerkschnittstelle PTP-Timestamping auf Hardwareebene unterstützt.
   • Der Raspberry Pi 5 eignet sich besonders gut, da er leistungsstärker ist und stabilere PPS-Latenzen liefert.
2. GPS-Empfänger mit PPS-Ausgang
   • Wichtig ist ein Modul, das neben den NMEA-Daten auch ein PPS-Signal (Pulse Per Second) liefert.
   • Beispiele:
     • u-blox NEO-6M / M6N / M8N
     • GlobalTop GMM-G3 (ältere Module, teilweise schwer erhältlich)
     • Trimble Resolution-SMT oder vergleichbare Module
   • Achte darauf, dass das Modul für eine externe Antenne geeignet ist und eine stabile 3,3V-TTL-Schnittstelle bietet.
3. GPS-Antenne
   • Eine aktive GPS-Antenne mit gutem Sichtfeld zum Himmel ist Pflicht.
   • Positioniere sie am besten am Fenster oder außerhalb des Gebäudes.
4. Stromversorgung & Kühlung
   • Für einen 24/7-Zeitserver ist ein stabiler Betrieb wichtig.
   • Verwende ein hochwertiges Netzteil (mind. 3A für Pi 4/5) und ggf. eine Kühlung (besonders beim Pi 5).
5. Software
   • Chrony oder ntpd für NTP-Zeitsynchronisation.
   • linuxptp (ptp4l, phc2sys) für PTP-Grandmaster-Funktion.
   • Optionale Tools für Monitoring (z. B. gpsmon, cgps).

3. Vorbereitungen

3.1 Raspberry Pi vorbereiten – Betriebssystem installieren

Damit der Raspberry Pi als GPS-gestützter Zeitserver arbeiten kann, braucht er ein aktuelles Betriebssystem. Ich empfehle die offizielle Linux-Distribution Raspberry Pi OS (64-Bit), die auf Debian Bookworm basiert. Sie wird von der Raspberry Pi Foundation gepflegt und bietet die beste Unterstützung für Hardware, Treiber und Tools wie chrony oder linuxptp.

3.1.1 Schritt 1: Raspberry Pi Imager verwenden

Die einfachste Möglichkeit, Raspberry Pi OS auf eine microSD-Karte zu bringen, ist der offizielle Raspberry Pi Imager. Diesen kann man kostenlos für Windows, macOS oder Linux von der Seite der Raspberry Pi Foundation herunterladen.

• microSD-Karte (mindestens 8 GB, besser 16 GB oder mehr) in den Kartenleser einlegen
• Raspberry Pi Imager starten
• „Raspberry Pi OS (64-bit)“ auswählen
• Version: Debian Bookworm (Stand 2025)
• Zielmedium (die microSD-Karte) auswählen
• Schreibvorgang starten

Nach wenigen Minuten ist das Betriebssystem fertig auf die Karte geschrieben.

3.1.2 Schritt 2: Erster Start des Raspberry Pi

• microSD-Karte in den Raspberry Pi einsetzen
• Monitor, Tastatur und Maus anschließen (optional, für die Grundkonfiguration; später geht alles per SSH)
• Strom anschließen, der Pi startet automatisch
• Erster Boot dauert ein wenig länger, weil das System die Dateien einrichtet
• Im Einrichtungsassistenten Land, Sprache, Tastatur und WLAN einstellen (falls genutzt)

3.1.3 Schritt 3: System aktuell halten

Sobald das System läuft, sollte man es gleich auf den neuesten Stand bringen:

sudo apt update
sudo apt upgrade -y

Damit ist das System vorbereitet, um später GPS und PPS einzubinden und daraus einen Stratum-1-Zeitserver bzw. eine Grandmaster Clock zu machen.

3.1.4 Persönliche Empfehlung

Ich habe für meinen Aufbau Raspberry Pi OS Bookworm 64-Bit verwendet, weil es die aktuelle, stabile Basis ist und alle wichtigen Pakete in aktuellen Versionen enthält. Für ein Projekt wie eine Grandmaster Clock ist ein solides, langfristig gepflegtes System entscheidend.

3.2 Verkabelung des GPS-Moduls mit dem Raspberry Pi (für Anfänger erklärt)

Der Raspberry Pi (ab Modell 3) hat eine 40-polige GPIO-Leiste, das ist die lange doppelreihige Stiftleiste am oberen Rand der Platine.

3.2.1 Orientierung der Pins

• Lege den Raspberry Pi so vor Dich hin, dass die USB-Buchsen nach rechts zeigen und die Netzwerkbuchse links daneben liegt.
• Die GPIO-Leiste befindet sich nun oben quer über die Platine.
• Pin 1 ist die linke obere Ecke dieser Leiste (ganz links außen).
• Die Pins sind in zwei Reihen angeordnet:
  • obere Reihe = ungerade Nummern (1, 3, 5, 7 …)
  • untere Reihe = gerade Nummern (2, 4, 6, 8 …)

3.2.2 Anschlussplan GPS-Modul (z. B. GY-GPS6MV2 mit NEO-6M)

1. Stromversorgung
   • GPS VCC (weißes Kabel) → Pin 1 (3,3 V, oben links außen)
   • GPS GND (schwarzes Kabel) → Pin 6 (GND, dritte Position unten rechts)
2. Serielle Verbindung
   • GPS RX (graues Kabel) → Pin 8 (TXD0, obere Reihe, vierter Pin von links)
     (Der Pi sendet Befehle zum Modul)
   • GPS TX (violettes Kabel) → Pin 10 (RXD0, untere Reihe, fünfter Pin von links)
     (Der Pi empfängt NMEA-Daten vom Modul)
3. PPS-Signal (Pulse Per Second)
   • Auf diesem GPS-Modul wird das PPS-Signal nicht als Pin herausgeführt.
   • Stattdessen kann man es an dem Vorwiderstand der Status-LED oder direkt am Modul abgreifen (siehe rote Kreise im Bild).
   • Dünnes Kabel anlöten (z. B. blauer Draht).
   • GPS PPS (blaues Kabel) → Pin 12 (GPIO18, obere Reihe, sechster Pin von links)

3.2.3 Hinweise für Einsteiger

• Achte darauf, wirklich Pin 1 als Ausgangspunkt zu nehmen, alle anderen Pins werden von dort gezählt.
• Nie die 5 V-Pins (Pin 2 oder Pin 4) verwenden, das Modul läuft intern mit 3,3 V, 5 V können es zerstören.
• Das angelötete PPS-Kabel am besten mit Heißkleber oder Schrumpfschlauch fixieren, damit es nicht abreißt.
• GND (Masse) muss immer verbunden sein, sonst funktioniert keine Kommunikation.

👉 Ergebnis: Mit nur 5 Kabeln (VCC, GND, RX, TX, PPS) hast Du ein funktionierendes GPS-Modul, das den Raspberry Pi mit exakter Zeit über NMEA-Daten und PPS-Impulse versorgt.

4. Installation

4.1 Raspberry Pi für GPS + PPS vorbereiten (Systemkonfiguration)

Damit der Raspberry Pi später das GPS-Modul korrekt anspricht und das PPS-Signal über GPIO18 nutzen kann, müssen ein paar Startparameter gesetzt werden. Diese liegen in den Konfigurationsdateien im Verzeichnis /boot/firmware/.

4.1.1 Kernel-Parameter anpassen (cmdline.txt)

Die Datei cmdline.txt enthält die Boot-Optionen für den Linux-Kernel. Sie besteht aus einer einzigen langen Zeile, in der verschiedene Parameter hintereinander stehen.

4.1.1.1 Bearbeiten mit vi:

sudo vi /boot/firmware/cmdline.txt

• Mit den Pfeiltasten ans Ende der Zeile gehen.
• Folgenden Parameter hinzufügen (mit Leerzeichen davor, falls direkt am letzten Wort):

nohz=off

• Speichern und beenden:
  • Esc drücken
  • :wq eingeben
  • Enter drücken

4.1.1.2 Erklärung:

• nohz=off
  • Deaktiviert den „Tickless Kernel“ Modus.
  • Normalerweise unterdrückt Linux unnötige Timer-Interrupts zur Energieeinsparung.
  • Für präzise Zeitmessung mit PPS brauchen wir jedoch stabile Takte, daher muss dieser Modus ausgeschaltet werden.

4.1.2 Gerätekonfiguration anpassen (config.txt)

Die Hardware-spezifischen Einstellungen für den Raspberry Pi stehen in config.txt.

4.1.2.1 Bearbeiten mit vi:

sudo vi /boot/firmware/config.txt

• Ganz nach unten scrollen, bis zum Bereich [ALL].
• Unterhalb von [ALL] folgende Zeilen einfügen:

enable_uart=1
dtoverlay=pi3-disable-bt
dtoverlay=pps-gpio,gpiopin=18

• Speichern und beenden (Esc, :wq, Enter).

4.1.2.2 Erklärung:

• enable_uart=1
  • Schaltet die serielle Schnittstelle (UART) frei.
  • Darüber empfängt der Pi die NMEA-Daten vom GPS-Modul.
• dtoverlay=pi3-disable-bt
  • Standardmäßig ist der UART-Port auf dem Pi mit dem Bluetooth-Modul verbunden.
  • Diese Einstellung deaktiviert Bluetooth und gibt den Port für das GPS-Modul frei.
• dtoverlay=pps-gpio,gpiopin=18
  • Bindet das PPS-Signal (Pulse Per Second) an GPIO18 (Pin 12) ein.
  • Das Betriebssystem erkennt das Signal später als /dev/pps0.

4.1.3 Neustart

Nach den Änderungen den Raspberry Pi neu starten, damit die Einstellungen aktiv werden:

sudo reboot

👉 Damit ist der Pi bereit, das GPS-Modul über die serielle Schnittstelle anzusprechen und das PPS-Signal auf GPIO18 als hochpräzise Sekundenmarke zu nutzen.

4.2 GPS- und PPS-Software auf dem Raspberry Pi installieren

Nachdem die Boot-Optionen angepasst wurden, muss der Raspberry Pi die GPS-Daten und das PPS-Signal auch auswerten können. Dafür installieren wir die passenden Pakete und richten den GPS-Daemon (gpsd) ein.

4.2.1 Benötigte Pakete installieren

sudo apt install screen gpsd gpsd-clients pps-tools

• gpsd – der GPS-Daemon, der die Daten vom Modul einsammelt und anderen Programmen zur Verfügung stellt
• gpsd-clients – kleine Hilfsprogramme wie cgps, um die GPS-Daten am Terminal anzeigen zu lassen
• pps-tools – Werkzeuge, um das PPS-Signal zu testen (ppstest)
• screen – ein Terminal-Multiplexer, mit dem man seriellen Output komfortabel ansehen kann

4.2.2 gpsd konfigurieren

Die Konfigurationsdatei liegt unter /etc/default/gpsd.

4.2.2.1 Bearbeiten mit vi:

sudo vi /etc/default/gpsd

Den Inhalt so einfügen (alte Inhalte ggf. ersetzen):

# Devices gpsd should collect to at boot time.
# Sie müssen für den Benutzer gpsd oder die Gruppe dialout lesbar sein.
DEVICES="/dev/ttyAMA0 /dev/pps0"

# Weitere Optionen für gpsd
GPSD_OPTIONS="-n"

# Automatisches Hotplugging von USB-GPS-Modulen deaktivieren
USBAUTO="false"

# gpsd beim Boot starten
START_DAEMON="true"

4.2.2.2 Erklärung:

• DEVICES=”/dev/ttyAMA0 /dev/pps0″
  • /dev/ttyAMA0 = die serielle Schnittstelle des Raspberry Pi, über die NMEA-Daten vom GPS kommen
  • /dev/pps0 = das PPS-Gerät (GPIO18), liefert die exakte Sekundenmarke
• GPSD_OPTIONS=”-n”
  • Normalerweise wartet gpsd, bis sich ein Client verbindet, bevor es das GPS-Modul abfragt.
  • Mit -n startet die Abfrage sofort beim Booten, dadurch steht die Zeit schneller zur Verfügung.
• USBAUTO=”false”
  • Wir verwenden ein fest verdrahtetes GPS-Modul, daher kein automatisches Einbinden von USB-Geräten.
• START_DAEMON=”true”
  • Sorgt dafür, dass gpsd beim Booten automatisch startet.

4.2.3 gpsd aktivieren und starten

sudo systemctl enable gpsd.service
sudo systemctl start gpsd.service

• enable sorgt dafür, dass gpsd bei jedem Neustart geladen wird.
• start startet gpsd sofort, ohne auf den nächsten Boot zu warten.

4.2.4 PPS-Modul beim Boot laden

Damit der Kernel das PPS-Signal immer erkennt, muss das Kernelmodul pps-gpio automatisch geladen werden.

4.2.4.1 Datei /etc/modules bearbeiten:

sudo vi /etc/modules

Am Ende der Datei hinzufügen:

pps-gpio

4.2.4.2 Erklärung:

• Jedes Mal, wenn der Pi bootet, wird dadurch das PPS-Modul geladen.
• In Verbindung mit dem Overlay-Eintrag in config.txt steht danach das Gerät /dev/pps0 immer bereit.

4.2.5 Neustart

Zum Abschluss den Raspberry Pi neu starten, damit alle Änderungen wirksam werden:

sudo reboot

👉 Danach läuft gpsd und stellt die GPS- sowie PPS-Daten im System zur Verfügung. Im nächsten Schritt sollte man prüfen, ob alles korrekt funktioniert, z. B. mit cgps -s für GPS-Daten und ppstest /dev/pps0 für das Sekunden-Signal.

4.3 Erster Test: Funktioniert GPS und PPS?

Nach dem Neustart prüfen wir zunächst, ob der Raspberry Pi sowohl das GPS-Modul als auch das PPS-Signal korrekt erkennt.

4.3.1 GPS-Daten mit cgps testen

Der Befehl:

cgps -s

Beispielausgabe:

┌──────────────────────────────────────────┐┌──────────────────────────────────────────┐
│    Time:       2025-10-02T14:10:58.000Z  ││PRN:   Elev: Azim: SNR: Used:            │
│    Latitude:   49.627369 N               ││  5     30   212   36    Y              │
│    Longitude:  10.609570 E               ││  9      9    77   11    Y              │
│    Alt (HAE,MSL): 315.2 m, 271.8 m       ││ 13     88   195   19    Y              │
│    Speed:      0.12 km/h                 ││ 14     63    95   28    Y              │
│    Track (true, var): 64.8 deg           ││ 15     56   291   28    Y              │
│    Climb:      0.01 m/s                  ││ 17     13   124   35    Y              │
│    Status:     3D FIX (231 secs)         ││ 21     11   185   42    Y              │
│                                          ││ 23     20   320   27    Y              │
│    Long Err  : 0.70, +/- 10.2 m          ││ 24      3   292   12    N              │
│    Lat Err   : 0.65, +/-  9.8 m          ││                                        │
│    Alt Err   : 1.05, +/- 38.1 m          ││                                        │
│    2D Err    : 0.92, +/- 23.7 m          ││                                        │
│    3D Err    : 1.41, +/- 39.4 m          ││                                        │
│    Time Err  : 0.71                      ││                                        │
│                                          ││                                        │
└──────────────────────────────────────────┘└──────────────────────────────────────────┘

4.3.1.1 Erklärung:

• Time: Aktuelle GPS-Zeit, hier in UTC.
• Latitude / Longitude: Geographische Position (in diesem Beispiel anonymisiert für Altschauerberg bei Neustadt a. d. Aisch).
• Alt (HAE, MSL): Höhe über Meeresspiegel in Metern.
• Speed / Track / Climb: Geschwindigkeit, Kurs und Steigrate (praktisch null, wenn das Modul stationär ist).
• Status: „3D FIX“ bedeutet, dass mindestens vier Satelliten empfangen werden, damit sind Höhe, Breite und Länge bestimmt.

Fehlerabschätzungen (DOP-Werte):

• HDOP (Horizontal Dilution of Precision): Genauigkeit in der Ebene.
• VDOP (Vertical DOP): Genauigkeit in der Höhe.
• PDOP (Position DOP): Kombinierte Genauigkeit in 3D.
• TDOP (Time DOP): Genauigkeit der Zeitangabe.

Satellitentabelle:

• GNSS: System (GP = GPS, GL = GLONASS, GA = Galileo, etc.).
• PRN: Kennnummer des Satelliten.
• Elev / Azim: Position des Satelliten am Himmel (Elevation = Höhe über Horizont, Azimuth = Himmelsrichtung).
• SNR: Signal-Rausch-Verhältnis (je höher, desto besser).
• Used: „Y“ = wird zur Positionsberechnung genutzt, „N“ = wird zwar empfangen, aber nicht verwendet.

4.3.2 PPS-Signal prüfen

Mit folgendem Befehl überprüfen wir, ob das Pulse-Per-Second-Signal korrekt ankommt:

sudo ppstest /dev/pps0

Beispielausgabe:

trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1759396350.006310981, sequence: 16
source 0 - assert 1759396351.006317035, sequence: 17
source 0 - assert 1759396352.006323317, sequence: 18
source 0 - assert 1759396353.006330048, sequence: 19
...

4.3.2.1 Erklärung:

• Jede Zeile zeigt einen Impuls pro Sekunde („Pulse Per Second“).
• assert: Zeitstempel des PPS-Signals in Sekunden seit UNIX-Epoch.
• sequence: fortlaufender Zähler, zeigt, dass die Impulse regelmäßig eintreffen.

Wenn man pro Sekunde eine neue Zeile sieht, funktioniert das PPS-Signal korrekt.

4.3.3 Fazit zum Test

• cgps -s bestätigt: GPS-Modul empfängt Satelliten und liefert Position + Zeit.
• ppstest bestätigt: PPS-Signal wird erkannt und kommt exakt jede Sekunde.

👉 Damit ist die Grundlage geschaffen, um den Raspberry Pi als Stratum-1 NTP/PTP Zeitserver zu nutzen.

4.4 Installation des Network Time Protokoll Daemon

4.4.1 Warum Chrony (und was ist der Unterschied zu NTP/ntpd)?

NTP/ntpd ist der „Klassiker“ für Zeitsynchronisation. Chrony ist eine modernere Implementierung, die besonders gut mit schwankenden Latenzen, instabilen Quellen, kurzen Online-Phasen und PPS-Signalen klarkommt. In der Praxis sind das die wichtigsten Unterschiede:

• Konvergenz & Stabilität: Chrony passt die lokale Uhr schneller und stabiler an (kürzere Lock-Zeit, robust gegen Jitter).
• Guter Umgang mit PPS: Chrony kann ein serielles NMEA-Signal (GPSD) mit PPS sehr präzise „verheiraten“ (Lock).
• Besser bei Last/Packet-Delay: Chrony modelliert Netzwerk-Delay und Drift aggressiver → genauere Ergebnisse in „normalen“ Netzen.
• Ressourcen & Pflege: Schlank, Standard unter Debian/Raspberry Pi OS (Bookworm).
• ntpd/ntpsec: weiterhin solide, in vielen Umgebungen bewährt; Chrony ist jedoch meist genauer und reagiert flinker.

Kurz: Für einen GPS/PPS-basierten Stratum-1-Server ist Chrony erste Wahl, darum verwende ich es im Folgenden.

4.4.2 Installation von Chrony

sudo apt install chrony

Danach läuft der Dienst in der Regel bereits. Falls auf dem System noch systemd-timesyncd aktiv ist, kann man ihn abschalten:

sudo systemctl disable --now systemd-timesyncd.service 2>/dev/null || true

4.4.3 Konfiguration für GPS + PPS (Deine Datei)

Öffne die Hauptkonfiguration:

sudo vi /etc/chrony/chrony.conf

Trage folgenden Inhalt ein (oder ergänze ihn entsprechend), dieser Block entspricht Deiner Vorlage:

###############################################################################
# Chrony Konfiguration - Raspberry Pi als Stratum-1 Zeitserver (GPS/PPS)
###############################################################################

# ---------------------------------------------------------------------------
# Einbinden zusätzlicher Konfigurationsdateien
# ---------------------------------------------------------------------------
confdir /etc/chrony/conf.d
sourcedir /etc/chrony/sources.d

# ---------------------------------------------------------------------------
# Authentifizierung und Drift-Korrektur
# ---------------------------------------------------------------------------
# Schlüssel für NTP-Authentifizierung (normalerweise nicht genutzt)
keyfile /etc/chrony/chrony.keys

# Datei für Frequenzabweichung des lokalen Quarzes
driftfile /var/lib/chrony/chrony.drift

# Ablage für NTS-Cookies (falls Network Time Security genutzt wird)
ntsdumpdir /var/lib/chrony

# ---------------------------------------------------------------------------
# Logging
# ---------------------------------------------------------------------------
# Logdateien für Diagnose (tracking, measurements, statistics)
logdir /var/log/chrony

# ---------------------------------------------------------------------------
# Systemzeit / RTC
# ---------------------------------------------------------------------------
# Kernel synchronisiert alle 11 Minuten die Hardware-Uhr (RTC)
rtcsync

# Zeitzone für Schaltsekunden (TAI-UTC Differenz)
leapsectz right/UTC

# Wenn Abweichung >1 Sekunde beim Start, dann harter Sprung (statt langsames Slewing)
makestep 1.0 -1

# ---------------------------------------------------------------------------
# Initial-Start: Schneller Grob-Sync gegen PTB-Zeitserver
# (nur beim Booten, um große Abweichungen sofort zu korrigieren)
# ---------------------------------------------------------------------------
initstepslew 60 ptbtime1.ptb.de ptbtime2.ptb.de ptbtime3.ptb.de

# ---------------------------------------------------------------------------
# Zeitquellen
# ---------------------------------------------------------------------------

# GPS über gpsd (Unix-Socket)
refclock SOCK /var/run/chrony.ttyAMA0.sock refid GPS precision 1e-1 poll 3

# PPS-Signal für exakte Zeitsynchronisation
# -> "lock GPS" bedeutet: PPS wird nur akzeptiert, wenn auch GPS-Signal gültig
refclock SOCK /var/run/chrony.pps0.sock refid PPS precision 1e-7 lock GPS poll 3

# PTB-Server als Backup und Vergleichsquelle (nicht zur Steuerung genutzt)
server ptbtime1.ptb.de iburst minpoll 5 maxpoll 5 noselect prefer
server ptbtime2.ptb.de iburst minpoll 5 maxpoll 5 noselect
server ptbtime3.ptb.de iburst minpoll 5 maxpoll 5 noselect

# Lokale Stratum-Gewichtung: sorgt dafür, dass GPS/PPS Vorrang hat
stratumweight 0

# ---------------------------------------------------------------------------
# Zugriffskontrolle
# ---------------------------------------------------------------------------
# Erlaubt NTP-Abfragen aus dem internen Netz (hier 10.10.0.0/17)
allow 10.10.0.0/17

Speichern und neu starten:

sudo systemctl restart chrony

4.4.3.1 Was bewirkt jede Zeile? (Erklärung & sinnvolle Anpassungen)

confdir / sourcedir

• Erlaubt Dir, Zusatzdateien sauber abzulegen (z. B. weitere Server oder Sonderregeln).
• Optional, aber ordentlich.

keyfile / driftfile / ntsdumpdir

• driftfile: Chrony lernt die Frequenzabweichung Deines Quarzes → stabilere Zeit.
• keyfile: Nur nötig, wenn Du klassisches NTP-Auth nutzt.
• ntsdumpdir: Ablage für NTS-Cookies (falls Du NTS einsetzt).

logdir

• Schreibt Diagnose-Logs (z. B. tracking, measurements, statistics) nach /var/log/chrony.
• Hilfreich bei Fehlersuche.

rtcsync

• Schaltet den Kernel-Mechanismus ein, die Hardware-Uhr (RTC) alle 11 Minuten mit der Systemzeit zu beschreiben.
• Sinnvoll, damit der Pi beim Neustart nicht völlig „daneben“ liegt.

leapsectz right/UTC

• Nutzt die „right/UTC“-Zone mit Schaltsekunden-Information.
• So bleiben Sprünge korrekt modelliert.

makestep 1.0 -1

• Wenn die Abweichung größer als 1 s ist, wird gesteppt (harte Korrektur).
• -1 bedeutet: diese Regel gilt unbegrenzt (auch später, nicht nur beim Boot).
• ↳ Für einen Zeitserver sinnvoll, um grobe Fehler zügig zu korrigieren.

initstepslew 60 ptbtime{1..3}.ptb.de

• Beim Booten (nur initial) darf Chrony bis 60 s sofort „steppen“, basierend auf externen PTB-Servern.
• Beschleunigt den Erst-Sync, falls GPS noch keinen Fix hat.
• Optional anpassbar: Du kannst hier eigene, nahe externe Zeitserver verwenden.

refclock SOCK /var/run/chrony.ttyAMA0.sock …

• Bindet die NMEA-Zeit ein, die gpsd über den Chrony-SOCK bereitstellt.
• refid GPS → Klarer Name in chronyc sources.
• precision 1e-1 ≈ 0,1 s – typisch für NMEA.
• poll 3 → Poll-Intervall 2^3 = 8 s.
• Wichtig: Der Pfad setzt voraus, dass gpsd die Chrony-SOCK-Sockets anlegt (in Debian/RPi-OS üblich, wenn DEVICES gesetzt sind).
  • Falls die Pfade bei einem System abweichen, prüfe mit ls /var/run/chrony.*.sock.

refclock SOCK /var/run/….pps0.sock … lock GPS

• Bindet PPS ein (die präzise Sekundenmarke).
• precision 1e-7 ≈ 100 ns – real erreichbare Genauigkeit ist natürlich systemabhängig, aber deutlich besser als NMEA.
• lock GPS → PPS wird nur verwendet, wenn GPS valide ist (vermeidet „freie“ PPS-Ticks ohne Bezug).
• poll 3 → 8 s Abtastung (ausreichend, PPS kommt ja jede Sekunde).

server ptbtime.ptb.de … noselect*

• Nutzt PTB-Server nur als Vergleich/Monitoring, nicht zur Steuerung (noselect).
• iburst beschleunigt den Start.
• minpoll/maxpoll 5 → 32 s Poll-Intervall, gleichbleibend.
• Hinweis: prefer hat in Kombination mit noselect keine Wirkung (optional entfernen oder belassen, es stört nicht).

stratumweight 0

• Deaktiviert die (geringe) Standardbevorzugung niedriger Strata.
• Damit gewinnen lokales GPS/PPS tatsächlich die Oberhand.

allow 10.10.0.0/17

• Erlaubt NTP-Anfragen aus Deinem LAN. Anpassen an das eigene Netz (z. B. 192.168.1.0/24).
• Optional mehrere allow-Zeilen für weitere Netze.

4.4.4 Rechteproblem bei Chrony-Sockets lösen

Standardmäßig legt Chrony die GPS- und PPS-Sockets unter /var/run/ an. Ohne Anpassung können andere Prozesse (z. B. gpsd) diese nicht immer verwenden.
Um das zu korrigieren, ergänzen wir einen ExecStartPost-Befehl in der Systemd-Unit von Chrony:

sudo systemctl edit chrony.service

Im Editor folgenden Block einfügen:

[Service]
ExecStartPost=/bin/sh -c '/bin/chmod 666 /var/run/chrony.ttyAMA0.sock /var/run/chrony.pps0.sock || true'

Speichern und beenden.

Damit wird nach jedem Start von chronyd ein chmod 666 auf die beiden Socket-Dateien ausgeführt. Das bedeutet: alle Benutzer dürfen lesen und schreiben, das löst zuverlässig das Rechteproblem.

Anschließend:

sudo systemctl daemon-reload
sudo systemctl restart chrony

4.4.5 Neustart & Kontrolle

sudo reboot

Prüfen:

ls -l /var/run/chrony*.sock

Die Dateien sollten nun rw-rw-rw- (666) haben.

4.4.6 Dienst prüfen

Nach dem Neustart:

sudo systemctl status chrony --no-pager
chronyc sources -v
chronyc tracking
chronyc sourcestats -v

Erwartung:

• In sources siehst Du GPS (NMEA) und PPS als Quellen; PTB-Server erscheinen mit x (noselect).
• tracking zeigt geringe „Last offset“-Werte (nach kurzer Einregelzeit).
• sourcestats gibt Jitter/Offset-Statistiken je Quelle aus.

4.4.7 Was muss man ggf. anpassen?

• Netz-Freigabe: allow … auf das eigene Subnetz ändern.
• Externe Server: initstepslew … auf eigene, zuverlässige Server anpassen (oder weglassen, wenn nur GPS/PPS gewünscht ist).
• SOCK-Pfade: Wenn gpsd auf Deiner Distribution andere Sockets anlegt, die Pfade in den refclock SOCK …-Zeilen entsprechend anpassen (mit ls /var/run/ prüfen).
• Firewall/Router: UDP/123 im LAN erlauben, damit Clients Deinen Pi als Zeitserver nutzen können.
• Zeitzone/Locale: Hat keinen Einfluss auf die UTC-Zeit, nur auf die lokale Darstellung.

4.5 Was ist PTP – und warum überhaupt?

PTP (IEEE 1588) ist ein Netzwerk-Protokoll zur hochpräzisen Zeitsynchronisation. Im Gegensatz zu NTP (typisch Millisekunden) erreicht PTP in lokalen Netzen Sub-Mikrosekunden bis Nanosekunden, vor allem wenn Hardware-Timestamping in der Netzwerkkarte (NIC) genutzt wird. Mit reinen Software-Timestamps landet man meist im Bereich einige 10 µs bis wenige ms, je nach Last und Netz. bootlin.com+2Oracle Docs+2

Wie funktioniert’s?
PTP verteilt Zeit in einer Hierarchie: Ein Grandmaster (GM) gibt die Referenzzeit vor (bei Dir: GPS/PPS → Chrony), Ordinary/Boundary Clocks folgen. Linux macht das mit linuxptp (Programme ptp4l, phc2sys). ptp4l spricht das Protokoll, phc2sys koppelt die PTP Hardware Clock (PHC) der NIC an die Systemuhr (oder umgekehrt). Red Hat Docs+1

4.5.1 Vorteil PTP

• Sehr hohe Genauigkeit im LAN (bis Sub-µs mit HW-Timestamps). bootlin.com
• Stabiler als NTP bei asynchronen Latenzen/Jitter. Red Hat
• Für Anwendungen mit strengen Timing-Anforderungen (Industrie/TSN, Telco, Hochfrequenzhandel u. ä.). Cisco

4.5.2 Realistische Erwartung mit Raspberry Pi

Ein Raspberry Pi mit GPS/PPS ist kein Meinberg-Grandmaster, dafür kostet er ~100 € statt ~20.000 €. Du bekommst sehr gute Ergebnisse für Labor, Heim- und viele KMU-Setups, aber nicht die letzten Nanosekunden im Worst-Case-Netz. Mit Hardware-Timestamping an der NIC sind sub-µs realistisch; mit Software-Timestamping eher < 100 µs bis ms. Quantum+1

Wichtig zu Raspberry-Pi-Modellen (HW-Timestamping):

• Pi 4 Model B: laut Raspberry-Pi-Forum kein HW-Timestamping. Raspberry Pi-Foren
• Compute Module 4/5: HW-Timestamping prinzipiell möglich, aber abhängig von Treiber/PHY-Support (Historie mit Treiber-/Firmware-Themen beachten). GitHub+1
• Pi 5: HW-Timestamping vorgesehen, es gab aber Treiber-Bugs/Issues in frühen Kerneln (Stand 2024). Prüfe Deinen Kernel/ethtool-Output. Alternativ bietet ein PCIe-NIC (z. B. Intel i210/i225/i226 auf HATs) sauberes HW-Timestamping. GitHub+1

4.5.3 PTP auf dem Raspberry Pi einrichten

4.5.3.1 linuxptp installieren

sudo apt install linuxptp

4.5.3.2 Prüfen, ob Deine NIC HW-Timestamping kann

ethtool -T eth0
ls -l /dev/ptp*

• HW-Timestamping: ethtool -T listet u. a. SOF_TIMESTAMPING_TX_HARDWARE, RX_HARDWARE; zudem existiert oft /dev/ptp0 (PHC).
• Nur Software-Timestamping: Es gibt keine/limitierte HW-Capabilities; /dev/ptp* fehlt. In diesem Fall läuft ptp4l weiterhin (mit geringerer Genauigkeit). docs.fedoraproject.org

Hinweis zu den Pi-Modellen s. oben, verifiziere immer mit ethtool -T, da Support vom Kernel/PHY abhängt. Raspberry Pi-Foren+1

4.5.4 Architektur festlegen

• Dein Setup: GPS/PPS → Chrony diszipliniert die Systemuhr.
• Mit HW-Timestamping: Synchronisiere die PHC der NIC mit der Systemuhr (phc2sys), ptp4l verteilt Zeit vom PHC ins Netz.
• Ohne HW-Timestamping: ptp4l nutzt die Systemuhr direkt (Software-Timestamps), Genauigkeit geringer, aber funktional. Red Hat Docs

4.5.4.1 Beispiel-Konfiguration (Grandmaster)

Lege z. B. /etc/linuxptp/ptp4l-gm.conf an:

[global]
#
# Default Data Set
#
twoStepFlag             1
#slaveOnly              0
socket_priority         0
priority1               128
priority2               128
domainNumber            0
utc_offset              37
clockClass              6
clockAccuracy           0x20
offsetScaledLogVariance 0x4000
free_running            0
freq_est_interval       1
dscp_event              0
dscp_general            0
dataset_comparison      ieee1588
G.8275.defaultDS.localPriority  128
maxStepsRemoved         255
#
# Port Data Set
#
logAnnounceInterval     1
logSyncInterval         0
operLogSyncInterval     0
logMinDelayReqInterval  0
logMinPdelayReqInterval 0
operLogPdelayReqInterval 0
announceReceiptTimeout  3
syncReceiptTimeout      0
delayAsymmetry          0
fault_reset_interval    4
neighborPropDelayThresh 20000000
gmCapable               1
masterOnly              1
G.8275.portDS.localPriority     128
asCapable               auto
BMCA                    ptp
inhibit_announce        0
inhibit_delay_req       0
ignore_source_id        0
#
# Run time options
#
assume_two_step         0
logging_level           6
path_trace_enabled      0
follow_up_info          0
hybrid_e2e              0
inhibit_multicast_service       0
net_sync_monitor        0
tc_spanning_tree        0
tx_timestamp_timeout    50
unicast_listen          0
unicast_master_table    0
unicast_req_duration    3600
use_syslog              1
verbose                 0
summary_interval        0
kernel_leap             1
check_fup_sync          0
#
# Servo Options
#
pi_proportional_const   0.0
pi_integral_const       0.0
pi_proportional_scale   0.0
pi_proportional_exponent        -0.3
pi_proportional_norm_max        0.7
pi_integral_scale       0.0
pi_integral_exponent    0.4
pi_integral_norm_max    0.3
step_threshold          0.0
first_step_threshold    0.00002
max_frequency           900000000
clock_servo             pi
sanity_freq_limit       200000000
ntpshm_segment          0
msg_interval_request    0
servo_num_offset_values 10
servo_offset_threshold  0
write_phase_mode        0
#
# Transport options
#
transportSpecific       0x0
ptp_dst_mac             01:1B:19:00:00:00
p2p_dst_mac             01:80:C2:00:00:0E
udp_ttl                 1
udp6_scope              0x0E
uds_address             /var/run/ptp4l
#
# Default interface options
#
clock_type              OC
network_transport       UDPv4
delay_mechanism         E2E
time_stamping           hardware
tsproc_mode             filter
delay_filter            moving_median
delay_filter_length     10
egressLatency           0
ingressLatency          0
boundary_clock_jbod     0
#
# Clock description
#
productDescription      ;;
revisionData            ;;
manufacturerIdentity    00:00:00
userDescription         ;
timeSource              0x20

Erläuterung:

• priority1 steuert die BMCA-Wahl (kleiner = „wichtiger“). Default ist 128. Für einen einzigen GM ist 127 ein guter Wert. Linux PTP Project+1
• clockClass/clockAccuracy/timeSource signalisieren Qualität des GM (GNSS-basiert). Vorgaben wie Class 6 und timeSource 0x20 sind verbreitet. Red Hat Docs+1
• network_transport: Viele Clients sprechen UDPv4. Manche Industrie-Geräte erwarten L2 (IEEE 802.3).
• domainNumber: Alle Teilnehmer innerhalb derselben Domain müssen denselben Wert nutzen (default 0). Debian Manpages

4.5.5 Dienste starten

4.5.5.1 Variante A – HW-Timestamping vorhanden (empfohlen)

1. PHC ↔ Systemuhr koppeln (Systemuhr stammt von Chrony/GPS):

# PHC (z.B. /dev/ptp0) an CLOCK_REALTIME anbinden:
sudo phc2sys -a -r -m
# oder explizit:
# sudo phc2sys -s CLOCK_REALTIME -c /dev/ptp0 -O 0 -m

2. ptp4l als Grandmaster starten:

sudo ptp4l -f /etc/linuxptp/ptp4l-gm.conf -i eth0 -m

4.5.5.2 Variante B – nur Software-Timestamping

sudo ptp4l -f /etc/linuxptp/ptp4l-gm.conf -i eth0 -m -S

-S erzwingt Software-Timestamping; ptp4l nutzt die von Chrony stabilisierte Systemzeit. Genauigkeit ist geringer, aber für viele Szenarien ausreichend. docs.fedoraproject.org

4.5.6 PTP als Systemdienst einrichten

Bisher haben wir ptp4l und phc2sys nur manuell gestartet. Damit Dein Raspberry Pi dauerhaft als Grandmaster arbeitet, sollten die Dienste automatisch beim Booten starten. Das erreichen wir über systemd-Unit-Dateien.

4.5.6.1 Variablen- und Standardwerte hinterlegen

Zuerst legen wir eine Konfigurationsdatei an, in der wir zentrale Werte wie Netzwerkschnittstelle und Optionen für ptp4l/phc2sys ablegen.

sudo install -d -m 0755 /etc/default
sudo tee /etc/default/linuxptp >/dev/null <<'EOF'
# Netzwerkschnittstelle für PTP (ggf. anpassen, z. B. eth0 oder end0)
IFACE=eth0

# Quelle für phc2sys:
# CLOCK_REALTIME = von Chrony/GPS geführte Systemzeit
# Alternativ könnte man auch eine PHC als Quelle nehmen
PHC2SYS_SRC=CLOCK_REALTIME

# Zusatzoptionen für ptp4l (z. B. -S für Software-Timestamps)
PTP4L_EXTRA_OPTS=""

# Zusatzoptionen für phc2sys
# -O 0 bedeutet: kein Offset zwischen Systemuhr und PHC
PHC2SYS_EXTRA_OPTS="-O 0"
EOF

Erklärung:

• IFACE=eth0 → Name des Netzwerkinterfaces, über das PTP läuft. Anpassen, falls Dein Pi z. B. end0 oder enx… heißt.
• PHC2SYS_SRC=CLOCK_REALTIME → Die von Chrony stabilisierte Systemzeit ist die Referenz. Sie wird auf die Hardware Clock (PHC) der NIC übertragen.
• PTP4L_EXTRA_OPTS → Hier kann man Zusatzparameter hinterlegen, z. B. -S, wenn die NIC kein Hardware-Timestamping unterstützt.
• PHC2SYS_EXTRA_OPTS="-O 0" → Kein zusätzlicher Offset, also 1:1-Übernahme der Chrony-Zeit in die PHC.

4.5.6.2 systemd-Unit für ptp4l (Grandmaster)

Nun erstellen wir die Service-Datei für den eigentlichen PTP Grandmaster-Dienst:

sudo tee /etc/systemd/system/ptp4l-gm.service >/dev/null <<'EOF'
[Unit]
Description=PTP Grandmaster (ptp4l)
Documentation=man:ptp4l(8)
After=network-online.target chrony.service
Wants=network-online.target

[Service]
Type=simple
EnvironmentFile=-/etc/default/linuxptp
ExecStart=/usr/sbin/ptp4l -f /etc/linuxptp/ptp4l.conf -i $IFACE -m $PTP4L_EXTRA_OPTS
Restart=on-failure
RestartSec=2

[Install]
WantedBy=multi-user.target
EOF

Erklärung:

• After=network-online.target chrony.service → Startet erst, wenn Netzwerk und Chrony laufen.
• ExecStart=… → Startet ptp4l mit der Konfigurationsdatei /etc/linuxptp/ptp4l.conf.
• -i $IFACE → Verwendet das in /etc/default/linuxptp angegebene Interface.
• -m → Loggt Nachrichten direkt ins Journal, damit man mit journalctl -u ptp4l-gm mitlesen kann.
• Restart=on-failure → Falls der Dienst abstürzt, wird er automatisch neu gestartet.

4.5.6.3 systemd-Unit für phc2sys

Damit die PHC der Netzwerkkarte kontinuierlich mit der von Chrony geführten Systemzeit synchronisiert wird, erstellen wir einen zweiten Dienst:

sudo tee /etc/systemd/system/phc2sys-gm.service >/dev/null <<'EOF'
[Unit]
Description=Sync NIC PHC with GPS-synced system clock (phc2sys)
Documentation=man:phc2sys(8)
After=ptp4l-gm.service chrony.service
Requires=ptp4l-gm.service

[Service]
Type=simple
EnvironmentFile=-/etc/default/linuxptp
# Systemzeit (Chrony/GPS) -> PHC der NIC
ExecStart=/usr/sbin/phc2sys -w -s $PHC2SYS_SRC -c $IFACE -m $PHC2SYS_EXTRA_OPTS
Restart=on-failure
RestartSec=2

[Install]
WantedBy=multi-user.target
EOF

Erklärung:

• Requires=ptp4l-gm.service → Startet nur, wenn auch ptp4l läuft.
• -s $PHC2SYS_SRC → Quelle, hier CLOCK_REALTIME (die von Chrony geführte Systemzeit).
• -c $IFACE → Ziel, die PHC des angegebenen Interfaces.
• -w → Wartet, bis PTP läuft, bevor synchronisiert wird.
• -m → Loggt ins Journal.

4.5.6.4 Dienste aktivieren

Nach Anlegen der Dateien muss systemd die neuen Units einlesen und aktivieren:

sudo systemctl daemon-reload
sudo systemctl enable --now ptp4l-gm.service phc2sys-gm.service

• daemon-reload → Systemd liest die neuen Unit-Dateien ein.
• enable --now → Aktiviert die Dienste für den Autostart und startet sie sofort.

4.5.6.5 Kontrolle

• Status prüfen: systemctl status ptp4l-gm.service phc2sys-gm.service
• Logs mitlesen: journalctl -u ptp4l-gm -f journalctl -u phc2sys-gm -f
• PMCTest: pmc -u -b 0 'GET CURRENT_DATA_SET' pmc -u -b 0 'GET TIME_STATUS_NP'

Damit läuft Dein Raspberry Pi 24/7 als GPS-synchronisierter PTP Grandmaster.

4.5.7 Das Problem mit den Schaltsekunden

Im Jahr 2025 haben wir derzeit +37 Schaltsekunden. Diese sind auch in der Konfiguration vorgesehen worden. Aber wenn jetzt mal eine Abfrage der Parameter gemacht wird, wird diese Korrektur zur UTC Zeit als nicht gültig deklariert:

sudo pmc -u -b 0 -t 0 'GET GRANDMASTER_SETTINGS_NP'

Das Ergbnis sieht dann wie folgt aus:

sending: GET GRANDMASTER_SETTINGS_NP
2ccf67.fffe.fccc11-0 seq 0 RESPONSE MANAGEMENT GRANDMASTER_SETTINGS_NP
clockClass              6
clockAccuracy           0x20
offsetScaledLogVariance 0x4000
currentUtcOffset        37
leap61                  0
leap59                  0
currentUtcOffsetValid   0
ptpTimescale            0
timeTraceable           0
frequencyTraceable      0
timeSource              0x20

Es müssen noch die Parameter currentUtcOffsetValid, ptpTimescale und timeTraceable auf “1” gesetzt werden. Das geht am einfachsten über ein Management Befehl:

sudo pmc -u -b 0 -t 0 "SET GRANDMASTER_SETTINGS_NP \
clockClass 6 \
clockAccuracy 0x20 \
offsetScaledLogVariance 0x4000 \
currentUtcOffset 37 \
leap61 0 \
leap59 0 \
currentUtcOffsetValid 1 \
ptpTimescale 1 \
timeTraceable 1 \
frequencyTraceable 0 \
timeSource 0x20"

Damit nach einem Neustart das ganze automatisch erledigt wird, setze ich ein kleines Shellskript ein, das als Daemon automatisch gestartet wird, wenn der Prozess ptp4l initialisiert wurde und die Uhrzeit sich stabilisiert hat.

sudo tee /usr/local/sbin/ptp-gm-flags.sh >/dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

SOCKET="/var/run/ptp4l"   # passt zu deiner ptp4l.conf
DOMAIN="0"
TS="0"
PMC="$(command -v pmc || echo /usr/sbin/pmc)"

# auf UDS-Socket warten (max ~2min)
for i in {1..240}; do
  [[ -S "$SOCKET" ]] && break
  sleep 0.5
done
[[ -S "$SOCKET" ]] || { echo "ERROR: ptp4l-Socket fehlt: $SOCKET"; exit 1; }

# auf MASTER-State warten (max ~5min)
for i in {1..600}; do
  if "$PMC" -u -s "$SOCKET" -b "$DOMAIN" 'GET PORT_DATA_SET' | grep -q 'portState.*MASTER'; then
    break
  fi
  sleep 0.5
done

# Flags setzen (kompletter Satz)
"$PMC" -u -s "$SOCKET" -b "$DOMAIN" -t "$TS" \
"SET GRANDMASTER_SETTINGS_NP clockClass 6 clockAccuracy 0x20 offsetScaledLogVariance 0x4000 currentUtcOffset 37 leap61 0 leap59 0 currentUtcOffsetValid 1 ptpTimescale 1 timeTraceable 1 frequencyTraceable 0 timeSource 0x20"

# verifizieren (loggt ins Journal)
"$PMC" -u -s "$SOCKET" -b "$DOMAIN" 'GET TIME_PROPERTIES_DATA_SET' || true
EOF
sudo chmod +x /usr/local/sbin/ptp-gm-flags.sh

Jetzt die beiden Dienste:

sudo tee /etc/systemd/system/ptp-gm-flags.service >/dev/null <<'EOF'
[Unit]
Description=Setze GM-Flags (UTC valid, traceable) nach ptp4l-Start
After=network-online.target
Wants=network-online.target
StartLimitIntervalSec=0

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/ptp-gm-flags.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF

und

sudo tee /etc/systemd/system/ptp-gm-flags.path >/dev/null <<'EOF'
[Unit]
Description=Watch for ptp4l socket and set GM flags

[Path]
PathExists=/var/run/ptp4l
Persistent=true

[Install]
WantedBy=multi-user.target
EOF

Danach die Dienste aktivieren und starten:

sudo systemctl daemon-reload
sudo systemctl enable --now ptp-gm-flags.service
sudo systemctl enable --now ptp-gm-flags.path
sudo systemctl start ptp-gm-flags.service
sudo systemctl start ptp-gm-flags.path

4.5.8 (Optional) NIC-Tuning bei Pi 5 / Intel-NIC

Einige Treiber bündeln Pakete (Coalescing). Geringere Latenzen bringen oft bessere PTP-Stabilität:

sudo ethtool -C eth0 rx-usecs 4 tx-usecs 4

(Beim Boot per systemd-Unit setzen.) Austin’s Nerdy Things

4.5.9^ Was muss man anpassen?

• Interface-Name: eth0 ggf. auf enx…/end0 ändern.
• PTP-Domain: domainNumber (Pi & Clients identisch). Debian Manpages
• Transport: UDPv4 vs. L2 je nach Client.
• Prioritäten/Policy: priority1/2, clockClass/Accuracy gemäß Deiner Rolle/Compliance. Linux PTP Project+1
• HW-TS-Support: Mit ethtool -T verifizieren; bei Problemen Kernel/NIC-Treiber prüfen (Pi 5/CM4 hatten bekannte Issues). Alternativ PCIe-Intel-NIC nutzen. GitHub+2GitHub+2

5. Fazit – vom Bastelprojekt zum ernstzunehmenden Zeitserver

Mit vergleichsweise geringem Aufwand lässt sich aus einem Raspberry Pi, einem GPS-Modul mit PPS-Ausgang und der passenden Software ein vollwertiger Stratum-1-Zeitserver aufbauen. Dank Chrony wird die Systemuhr des Pi präzise diszipliniert, während PPS die exakte Sekundenmarke liefert. In Kombination mit PTP (Precision Time Protocol) kann diese Zeit im lokalen Netz mit hoher Genauigkeit verteilt werden, weit über das hinaus, was klassisches NTP im Millisekundenbereich leistet.

Natürlich sollte man realistisch bleiben:
Ein Raspberry Pi mit GPS ist keine professionelle Meinberg-Grandmaster-Clock für fünfstellige Summen. In puncto Stabilität, Temperaturkompensation und absoluter Genauigkeit spielen die Industrieprodukte in einer ganz anderen Liga. Aber für rund 100 Euro Materialkosten erhält man eine Lösung, die im Labor, im Heimnetz, für VoIP-Telefonanlagen, Server-Umgebungen oder auch für kleinere Firmen vollkommen ausreicht, und in vielen Fällen eine Genauigkeit im Bereich von Mikrosekunden bis Millisekunden erreicht.

Die Vorteile liegen auf der Hand:

• Preis-Leistungs-Verhältnis: Für ein Zehntel bis Hundertstel der Kosten einer Profi-Clock erhält man eine solide Referenzzeit.
• Flexibilität: Mit Chrony, gpsd und linuxptp hat man volle Kontrolle über Konfiguration, Protokolle und Zugriffsrechte.
• Erweiterbarkeit: Der Zeitserver kann NTP und PTP parallel bedienen und damit praktisch alle Clients im Netzwerk versorgen.
• Lernfaktor: Man versteht im Detail, wie präzise Zeitverteilung funktioniert, etwas, das bei einer „Black Box“-Industrieuhr verborgen bleibt.

Wer den Raspberry Pi als Grandmaster einsetzt, sollte jedoch ein paar Punkte im Hinterkopf behalten: stabile Stromversorgung, gute GPS-Antenne mit freiem Himmel, korrekte PPS-Verdrahtung und ein Auge auf Kernel/Treiber, wenn es um Hardware-Timestamping geht.

Mein Fazit:
Ein Raspberry Pi als GPS-gestützter Zeitserver ist ein hervorragendes Projekt für alle, die Wert auf präzise Zeit im Netzwerk legen, sei es für Logging, Server, Telefonie oder einfach zum Lernen. Er ersetzt zwar keine professionelle Grandmaster-Clock in kritischen Infrastrukturen, doch für private und semi-professionelle Umgebungen ist er eine kostengünstige, praxisnahe und technisch spannende Lösung, die das Thema Zeitsynchronisation greifbar macht.