Die abschließenden restrict-Anweisungen regeln den Zugriff auf den NTP-Server. Hier ist es sinnvoll, allen Benutzern im Netz die Zeitinformation anzubieten, aber nur lokalen eine Einflussnahme auf den Zeitserver zuzulassen.
Listing 5
server 127.127.8.0 mode 5 prefer #fudge 127.127.8.0 time1 <statischer Zeitverzug> #server <NTP-Server> noselect logconfig =all driftfile /var/lib/ntp/ntp.drift statsdir /var/log/ntpstats/ statistics loopstats peerstats clockstats filegen loopstats file loopstats type day enable filegen peerstats file peerstats type day enable filegen clockstats file clockstats type day enable restrict -4 default kod notrap nomodify nopeer noquery restrict 127.0.0.1
Schaltungen
In Abbildung 3 sehen Sie die Schaltpläne für die DCF77-Module von Conrad und Pollin. Für andere Module gilt es, diesbezüglich deren Datenblatt zu Rat zu ziehen (siehe auch Kasten “Warnung”).
Die Antenne des Empfängermoduls positionieren Sie optimal, indem Sie den Ferrit-Stab waagerecht und quer zur Empfänger-Senderort-Achse ausrichten. Leistungsstarke Störer im oberen zweistelligen kHz-Bereich, wie etwa Schaltnetzteile, können den Empfang nachhaltig stören oder sogar ganz verhindern. Zwar ist mit dem CMOS-Eingang RXD keine große Last zu schalten, eine längere Leitung zwischen Empfängermodul und RasPi erfordert dennoch eine entsprechende Treiberstärke.
Beim Conrad-Modul handelt es sich bei DCF- um einen Open-Collector-Ausgang, dessen Laststrom Sie laut Datenblatt auf 1 mA begrenzen müssen. Das erfordert einen Pull-Up-Widerstand von mindestens 3 kOhm, wegen der geforderten Treiberstärke sollte er jedoch nicht 10 kOhm übersteigen.
Beim Pollin-Modul müssen Sie das Signal noch invertieren, etwa durch den CMOS-Inverter 74HC04, der auch gleich als Leitungstreiber dient. Der Power-On-Eingang (PON) würde es erlauben, das Modul über einen GPIO-Pin zu aktivieren – hier ist es auf Always-On konfiguriert.
Warnung
Vorsicht: Alle RasPi-I/O-Pins gehören zum 3,3-V-Signalpegeltyp und sind nicht kompatibel mit 5 V! Daher betreiben Sie sinnvollerweise das Empfängermodul bei 3,3 V Betriebsspannung. Prüfen Sie unbedingt dessen Kompatibilität im entsprechenden Datenblatt.
Inbetriebnahme
Ein erfolgreicher Hochlauf teilt sich in drei Phasen, die Sie mithilfe des Kommandos sudo tail -f /var/log/syslog mitverfolgen können. In der Initialphase liegt weder eine Drift-Information noch eine Zeitinformation vor. Sobald der Empfänger die erste Zeitinformation liefert, erfolgt eine Korrektur der Systemzeit, in den folgenden rund 16 Minuten ermittelt Ntpd eine erste Driftschätzung (Listing 6).
Listing 6
[...] Jul 9 20:00:10 raspberrypi ntpd[2712]: ntpd [email protected] Fri May 18 20:30:57 UTC 2012 (1) Jul 9 20:00:10 raspberrypi ntpd[2713]: proto: precision = 1.000 usec Jul 9 20:00:10 raspberrypi ntpd[2713]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123 Jul 9 20:00:10 raspberrypi ntpd[2713]: Listen normally on 1 lo 127.0.0.1 UDP 123 Jul 9 20:00:10 raspberrypi ntpd[2713]: peers refreshed Jul 9 20:00:10 raspberrypi ntpd[2713]: Listening on routing socket on fd #18 for interface updates Jul 9 20:00:10 raspberrypi ntpd[2713]: 0.0.0.0 c016 06 restart Jul 9 20:00:10 raspberrypi ntpd[2713]: 0.0.0.0 c012 02 freq_set kernel 0.000 PPM Jul 9 20:00:10 raspberrypi ntpd[2713]: 0.0.0.0 c011 01 freq_not_set Jul 9 20:00:44 raspberrypi ntpd[2713]: parse: convert_rawdcf: INCOMPLETE DATA -- time code only has 32 bits Jul 9 20:00:44 raspberrypi ntpd[2713]: PARSE receiver #0: interval for following error message class is at least 00:01:00 Jul 9 20:00:44 raspberrypi ntpd[2713]: PARSE receiver #0: FAILED TIMECODE: "#-##---##----#-RA-MLS--48--4p--" (check receiver configuration / wiring) Jul 9 20:01:44 raspberrypi ntpd[2713]: 0.0.0.0 c21c 0c clock_step +96555.648220 s Jul 10 22:51:00 raspberrypi ntpd[2713]: 0.0.0.0 c214 04 freq_mode Jul 10 22:51:00 raspberrypi ntpd[2713]: 0.0.0.0 c218 08 no_sys_peer [...] Jul 10 23:07:01 raspberrypi ntpd[2713]: 0.0.0.0 c212 02 freq_set kernel 72.701 PPM Jul 10 23:07:01 raspberrypi ntpd[2713]: 0.0.0.0 c215 05 clock_sync [...]
In der Einschwingphase wird die PLL mit den Sekundenpulsen beliefert, wobei der Zeit-Offset von mehreren 10 ms auf rund 1 ms absinkt. Diese Phase dauert rund zwei Stunden und endet mit dem Anlegen der Datei /var/lib/ntp/ntp.drift. Mit dem Aufruf:
$ tail -f /var/log/ntpstats/peerstats
können Sie in der fünften Spalte der Ausgabe das Abklingen der Zeitdifferenz (in Sekunden) zwischen der Zeitreferenz (dritte Spalte) und der lokalen Systemzeit verfolgen.
Danach tritt die PLL in die stabile Phase ein, die Zeitdifferenz der PLL “zittert” praktisch nur mehr noch den Mittelwert 0 oder folgt allenfalls einer langsamen Drift. Der NTP-Daemon aktualisiert dementsprechend regelmäßig das Drift-File.
Mit dem Programm ntpq aus dem Werkzeugkasten des NTP-Pakets steht ein weiteres Werkzeug zur Verfügung, mit dem Sie den Zustand des NTP-Zeitservers betrachten können:
$ watch -n 1 ntpq -c as -c cv -c rv
Das obige Kommando liefert im Sekundentakt eine Aufstellung der beobachteten NTP-Zeitserver beziehungsweise Zeitnormale sowie der wichtigsten Zustandsdaten.





