NTP für Pi-Hole. ein paar tips

Bordi · 26 June 2020 14:22

Hallo

Ich hab vor ner weile mein Pi-Hole zum Zeitserver meines Netzwerks gemacht. Umgesetz habe ich dies wie es wohl die meisten tun würden, und auch in diversen Anleitungen vorgegeben wird.

Das es doch sinnvoll sein könnte eine richtige Uhr zu verwenden, darüber begann ich erst mit dem post von @Bucking_Horn nachzudenken.

Die Entscheidung viel zuerst auf die High Accuracy RTC (DS3231) for Raspberry Pi von Seeed

Diew kleine Uhr kommt in einer kleinen Schachtel mit einen Schwamm drin, der die Platienen scvhützen und stabilisieren soll. Ansonsten ist da nichts. Keine Anleitung, keine Batterie (es wird eine CR1225 benötigt), kein Hinweis, nix. Geeicht ist die Uhr auf irgend ein Datum anno 2000.

Wer die Installation verkackt, der copy&past macht ohne zu lesen, der öffnet seine Website erst in 20 Jahren. Viel spass auch.

Der effect von der Uhr ist übrigens ziemlich gering. Eine Grund dafür ist der daß sie lediglich den tackt vorgibt, oder zumindest im off hält. Sie korrigiert sich aber nicht selbst, wie dies bei NTP der Fall ist. Also ideal um den Millennium-Bug zu reproduzieren, einen Pi-Hole ohne Strom die Sekunden zu takten. Wer darauf keinen Wert legt kann sich das ding getrost sparen. Auch weil in Raspian/RaspberryOS eine Fake-Uhr integriert wurde, welche den Raspbarry beim Reboot auf Kurs hält.

https://www.raspberrypi.org/forums/viewtopic.php?t=200385#p1248744

Schon viel besser, wäre eine Funkuhr. bevorzugt als Primär-Uhr mit NTP Rückendeckung. Wer selbst suchen möchte, sucht am besten nach einer DCF77. Die gibt es auch als HAT, ich hab mir jedoch eine USB-Lösung gesucht.

https://www.gude.info/funkuhrsysteme/dcf77-funkuhren/expert-mouse-clock-0107-usb.html

Die Anleitung findet sich online und stammt von 2017 (!11). Wer sich die Uhr ebenfalls zulegt, und ntp bereits installiert hat kann sich so ziemlich alles sparen.

Pi-Hole herunterfahren
Uhr Anstöpseln > booten
Nach Anleitung: symlink erstellen, udev anpassen, ntpd anpassen
Rebooten > fertig

http://wiki.gude.info/Ntpd_Installation#Configuring_serial_interface

Testen kann man die Uhr indem man das tarball ntpd plus den eigenen Mods ansaugt, und ohne 'make install' einmal alles compiliert, und für den test, ntpd stopt.

Eine alternative dazu wäre GPS, gibt es ebenfalls auch als HAT. Allerdings ist GPS bez. Empfang sehr "wählerisch". Außer unter freiem Himmel geht fas gar-nix.

Wer will kann all diese Uhren inkl der Internet-abfragen in /etc/ntp.conf konfigurieren. Wichtig ist daß man es richtig macht, nicht das die RTC mehr Priorität hat als beispielsweise die GPS-Uhr (welche ich jetzt nicht habe).

Falls ihr den DHCP von Pi-Hole nutzt, könnt ihr euren Clients die Zeit aufdrängen.

Um jedoch euer Modem vom ntp-traffic zu entlasten begebt ihr euch zu eurem http://pi.hole/admin/dns_records.php und bennent euer Pi-Hole nach den Zeitservern, die in eurem Netz abgefragt werden.

0.android.pool.ntp.org > Local-Pi-Hole-IPv4/6
0.sonostime.pool.ntp.org > Local-Pi-Hole-IPv4/6
0.debian.pool.ntp.org > Local-Pi-Hole-IPv4/6
time.windows.com > Local-Pi-Hole-IPv4/6
time.google.com > Local-Pi-Hole-IPv4/6
time.android.com > Local-Pi-Hole-IPv4/6
time-ios.apple.com > Local-Pi-Hole-IPv4/6
..usw

Bucking_Horn · 26 June 2020 16:56

Ein DCF77-Zeitempfänger und eine batteriegepufferte RTC decken unterschiedliche Anwendungsfälle ab.

In der Mehrheit der Fälle dürfte eine RTC ausreichen, um ein Heimnetzwerk mit einer Uhrzeit zu versorgen. (für Details klicken)

Deine Erwartungen passen nicht so ganz zu dem, was eine batteriegepufferte RTC leisten soll:
Es ist nicht das Ziel einer RTC, ein Zeitreferenzsignal zu liefern (und damit einen NTP-Server oder ein DCF-Signal zu ersetzen) oder sich eigenständig mit einer Uhrzeit zu versorgen.

Die Uhr soll im wesentlichen die eingestellte Uhrzeit und Datum über einen langen Zeitraum hinweg mit zuverlässiger Genauigkeit halten. Durch die Batterieversorgung bleibt die Zeit dabei nicht nur erhalten, sie läuft z.B. auch während eines Stromausfalls zuverlässig weiter.

Dadurch steht sofort und unmittelbar beim Einschalten die korrekte aktuelle Uhrzeit zur Verfügung (für Pi-hole ist das bei aktiviertem DNSSEC wichtig).

Die fake-hwclock eines RPi liest hingegen beim Start die letzte bekannte Zeit aus einer periodisch (standardmässig einmal pro Stunde) geschriebenen Datei.
Dadurch kann es schon nach einer kurzfristigen (unbeabsichtigten) Trennung der Stromversorgung zu Abweichungen von über einer Stunde kommen.

In der Regel wird anschliessend der Abgleich der lokalen Uhrzeit mit einem NTP-Server versucht (egal ob RTC oder Fake), was natürlich nur bei bestehender Netzwerkverbindung funktioniert.

NTP-Clients sind aber üblicherweise darauf ausgelegt, abrupte Zeitsprünge zu vermeiden. Sie werden daher nur bei kleineren zeitlichen Diskrepanzen unmittelbar eine neue Zeit setzen; größere Abweichungen allerdings werden skaliert und ggf. erst allmählich korrigiert.

Das kann schon einmal mehrere Minuten dauern, und über diesen Zeitraum ist dann u.U. auch keine erfolgreiche DNSSEC-Validierung möglich. Bei massiven Abweichungen können NTP-Clients sogar komplett die Anpassung verweigern. Dann hilft nur noch, die Uhrzeit manuell einzustellen.

Eine RTC dient also auch dazu, die Abweichung zwischen der Referenz-Zeit und der lokalen Zeit so minimal zu halten, dass NTP-Syncs möglichst geräuschlos funktionieren.

Mit einem DCF77-Zeitempfänger holt man sich zunächst einmal eine weitere Zeit-Referenz ins Netz, also eine zusätzliche Alternative zum Bezug der Zeit von einem öffentlichen NTP-Server.

Die Probleme mit der RTC bleiben Dir dabei aber prinzipiell erhalten.

Wenn Dein DCF77-USB-Dongle nicht batteriegepuffert arbeitet und über keine eigene RTC verfügt, wird ein Neustart auch hier erst einmal zu minutenlangen Zeitabweichungen führen: Schon allein die vollständige Neusynchronisation der Uhrzeit über DCF77 dauert im Minimum knapp 40 Sekunden, kann aber je nach Empfangsqualität auch schon mal zwei bis drei Minuten dauern. Der Abgleich der empfangenen Zeit mit der lokalen Zeit käme noch hinzu, wobei das wahrscheinlich vom Treiber geregelt wird und also ggf. auch sofort erfolgen kann.

Hinzu kommt die Genaugkeitsfrage: Über NTP können etwa 10ms erreicht werden.
Ich hab so'ne DCF-Uhr mal mit einem Kumpel in meiner Studentenzeit selbst gebaut: Solange man hier nur mit einem Schmalband-Empfänger arbeitet, ist ohne weiteres mit einer Abweichung von um die 100ms zu rechnen. Bessere Empfänger und Korrekturverfahren können das natürlich deutlich drücken. Aktuelle erreichbare Genauigkeiten müsste man nachschlagen, sie dürften NTP aber durchaus deutlich überbieten - vielleicht hilft auch ein Blick ins Datenblatt Deines DCF-Empfängers.

Es hängt letzlich von der konkreten Umsetzung dieses DCF77-Empfängers ab, wie genau die darüber bezogene Uhrzeit ist, und ob Du damit tatsächlich auch einen vollwertigen Ersatz für die RTC an Bord hast.

Es könnte sich also u.U. lohnen, die RTC trotz mangelhafter Installationsanleitung und/oder Softwareausstattung doch noch in Betrieb zu nehmen.

Bordi · 27 June 2020 02:19

Meine Aussage war eigentlich genau gegenteiliger Natur. Der Satz ist doof formuliert. Die RTC hat so gut wie keinen positiven Effekt. Nicht nur aber auch aufgrund der bereits vorhandenen Fake-Clock, welche die Systemzeit automatisch übernimmt, während dem booten hält, und nach dem booten lückenlos übergeben kann.

Die RTC gilt hingegen als unsynchronisiertes device. Bedeutung: Die RTC läuft Sekunden-genau weiter, auch oder obschon Zeit und/oder Datum komplett falsch sein können. Richten lässt sich der Misstand nur von Hand, und wird aufgrund der eigenen menschlichen Reaktionszeit nie präzise sein. Daher sollte sie frühestens ab Stratum 10 zum Einsatz kommen. Reference, das beste ist Stratum 0.

https://timetoolsltd.com/ntp/what-is-a-stratum-1-time-server/

Mit der Zeitsynchronisation über Internet und der Fake-Clock erreicht ihr bereits Stratum 3.

Bucking_Horn · 27 June 2020 09:07

Ich versuch's noch mal anders:

Das Problem, dass ein RPi bei einem Einsatz als Zeitserver hat, ist die fehlende Echtzeituhr (RTC).
Dadurch wird es bei Trennung von der Stromversorgung und/oder der Zeitreferenz zwangsweise zu Abweichungen kommen.

Das Hinzufügen einer zusätzlichen Zeitreferenz (egal ob DFC- oder Satellitenempfänger) löst dieses Problem ebensowenig wie die Verwendung von de.pool.ntp.org statt 0.debian.pool.ntp.org als alternativem NTP-Server dies täte.

fake-hwclock ist dabei nur ein mittelprächtiger RTC-Ersatz, und es ist auch keine Uhr, nicht einmal ansatzweise.
fake-hwclock macht genau eine Sache: Es schreibt beim Herunterfahren und periodisch einmal pro Stunde den aktuellen Zeitstempel aus der Systemuhr in eine Datei, damit diese beim Hochfahren ausgelesen und in die Systemuhr zurückgeschrieben werden kann. (Eine Hardware-RTC wird übrigens genauso behandelt: Beim Booten wird die aktuelle Zeit von der RTC in die Systemuhr übernommen, und beim Shutdown wird die Zeit umgekehrt aus der Systemuhr in die RTC geschrieben.)

Die Zeitsynchronisation läuft immer gegen die Systemuhr - weder fake-hwclock noch RTC sind hier beteiligt.

Fällt nun der Strom bei einem RPi für eine Minute aus, beträgt die dadurch entstandene Zeitabweichung im ungünstigsten Fall 1h 59s.
Dauert der Stromausfall länger, z.B. zwei Stunden, ist auch die maximale Abweichung entsprechend größer, also 3h 59s.
Habe ich den RPi ordnungsgemäß heruntergefahren habe, entspricht die Abweichung der Dauer der Abschaltung, also zwei Stunden nach zwei Stunden Auszeit.

Der Einsatz einer Echtzeituhr eliminiert diese Abweichung vollständig.

Die Einführung eines DCF77-Empfängers als zusätzliche Zeitreferenz empfiehlt sich für andere Anwendungsfälle.
Sie würde einem RPi z.B. erlauben, sich auch ohne Netzwerkverbindung eine aktuelle Uhrzeit zu besorgen.
Sie kann potentiall auch genauer als eine über NTP-Server bezogene Zeit sein, möglicherweise aber eben auch schlechter - das würde vom konkret verwendeten DCF-Empfänger abhängen. Die Genauigkeit spielt jedoch bei den üblichen Heim-Anwendungen zumeist eine untergeordnete Rolle.

msatter · 27 June 2020 10:14

Das Datum is immer ab auf meine test RasPI wenn die lange nicht benutzt ist.

Ich setze das Datum mit date -s 20200627 und einige Sekunden später ist auch die Zeit richtig:

Mon 22 Jun 14:15:59 CEST 2020
test@pihole2:~# date -s 20200627
Sat 27 Jun 00:00:00 CEST 2020

test@pihole2:~# date
Sat 27 Jun 12:03:37 CEST 2020

Irgend wo muss eine Einstellung sein die grossere Differenzen in zeit sorgt das die Zeit nicht übernommen wird.

Bordi · 27 June 2020 10:42

Deine Erklärungen sind erstklassig. Ich hätte eine Wiederholung nicht gebraucht. Schade ist daß du mich offenbar nicht ganz so gut verstehst.

Ein unsynchronisiertes device wird IMMER(!11) von der Synchronzeit abweichen. Ich weiß RTC -> 'real-time clock' -> 'Echtzeituhr' und so. Das verleitet zu glauben, daß man damit die richtige Zeit hat. Aber ebenen genau dies stimmt NICHT. Was die Uhr kann ist Hochpräzise Sekunde für Sekunde abzutakten. Was sie NICHT kann, ist sich mit einer anderen Uhr zu Synchronisieren. Große delay's sind da nicht untypisch.

Bedeutet: Wenn die RTC bei Stromausfall Stunden oder Jahren neben der Zeit ist, dann ist sie dabei wenigsten hochpräzise. Auch über Jahre. Und obschon du bei vielem recht hast, ist genau dies ein punkt wo die fake-hwclock ihren vielleicht einzigen vorteil hat. Insbesondere bei einem Server im 24/7 betrieb.

Beispiel: Gehen wir von einen Netzwerkausfall aus kann es mit der RTC gut sein daß du plötzlich Okt. 1999 hast. Einfach deswegen weil sie falsch oder nie richtig, oder wegen eines -vielleicht auch ausstehenden- Batteriewechsels, in der Zeit verrutsch ist, und sich nicht selbst synchronisieren kann (egal mit was). Bei der fake-hwclock ist dies anders. Selbiges gilt auch für Zeitgeber wie GPS, oder Funk welche sich synchronisieren können.
Anderes Scenario, diesmal auf einem Stratum 1 Server: Das Signal für den primär Zeitgeber (idr GPS, DCF77 o.ä.) fällt aus, eine Zeitreferenz zu einem NTP Server im Netz wurde nicht eingerichtet, was übrig bleibt ist die RTC welche direkt übernimmt. Wenn ab diesem Moment ein Client mit "ntpdate -q" diesen Zeitserver abfragt, erscheint die Meldung das dies ein asynchroner Stratum 11 Server (oder schlechter) ist, welcher nicht synchronisiert werden soll, oder kann. Super Uncool. Erst recht wenn die RTC die Systemzeit vorgibt.

Selbiges gilt selbstverständlich nicht nur für den unterschied zwischen Client, und lokalem Server. Sondern auch zwischen LAN und WAN. Wenn lokal Okt. 1999 vorgegeben, und von den Clients synchronisiert wird, ist dies erstmal kein Problem. Problematisch wird es erst wen du auf einen externen Server zugreifen möchtest welcher Jun. 2020 hat.
Ist diese Diskussion komplett für'n Ar*****. Es gibt Gründe weshalb käufliche Zeitserver und Netzwerk-Uhren die Zeit ab GPS, DCF oder ähnlich ziehen. Diesbezüglich darf man sich auch gerne bei Meinberg (31812 Bad Pyrmont) oder Gude (51149 Köln) -oder deren Branchenkonkurrenz- weitergehend informieren.

Ich hoffe du hast mich nun auch verstanden. Andernfalls, who cares. Als root hat jeder selbst das recht auf Moderatoren, Administratoren und Anleitungen zu *** wie es ihm passt. ..und das ist auch gut so.
Ein Schelm wer böses denkt.

Bucking_Horn · 27 June 2020 17:26

Ich habe alle Deine Antworten gelesen und stelle auch nach eingehender Lektüre Deiner Antwort fest:
Dein Verständnis des von mir angesprochenen Problems und Dein Verständnis von fake-hwclock sind definitiv falsch, wobei letzteres eventuell ersteres bedingt.

Das macht Deine darauf aufbauende Argumentation und Deine Beispiele ebenfalls falsch, irrelevant oder unbrauchbar.

Für den Fall, dass Du an einer sachlichen Auseinandersetzung weiterhin Interesse hast: Klicken für Details.

fake-hwclock wird niemals die Zeit mit einem NTP-Server oder irgendeiner anderen Quelle synchronisieren (egal ob Du root bist oder nicht).

In dieser Beziehung verhält sie sich exakt genauso wie eine batteriegepufferte Hardware-RTC.

Schauen wir uns einmal Deine Einwände an:

Nein, im Gegenteil:
Die meisten RTCs für Rechner sind alles andere als hochpräzise, der DS3231 gehört da schon zu den besseren - ein DS1307 kann z.B. fünf und mehr Sekunden pro Tag verlieren.

Das ist aber u.a. deshalb verschmerzbar, da beim Auslesen der Zeit aus einer Hardware-Uhr die vorhersehbare Zeitdrift korrigiert wird (was übrigens mit fake-hwclock überhaupt nicht geht, da es sich dabei ja nicht um eine Uhr handelt).

Und die Tatsache, dass eine RTC die Zeit nicht von sich aus synchronisiert, ist ebenfalls unerheblich, denn

Und für diese synchronisierte Zeit aus der Systemuhr gilt in der Regel (zumindest bei Linux-Systemen):

Die RTC-Zeit wird also durchaus synchronisiert, und zwar genauso indirekt wie fake-hwclock. Die Abweichung der RTC zur Systemzeit wird daher schon prinzipiell immer kleiner sein als die zwischen fake-hwclock und Systemzeit.

Darüber hinaus gibt es entsprechend kompilierte Linux-Kernel, die die Systemzeit zusätzlich alle 11 Minuten in die Hardware-RTC schreiben.

In Deinem Beispiel findet sich dann folgende Annahme:

Nein.
(Und wegen dieser Fehleinschätzung ist auch Dein Punkt 2. hinfällig)

Es ist im Gegenteil so, dass für den Betrieb eines NTP-Servers der Einsatz eines oben erwähnten 11-Minuten-Kernels empfohlen wird, der alle 11 Minuten die Zeit aus der Systemuhr in die RTC kopiert - und damit in die Deiner Annahme entgegengesetzte Richtung.

Es ist immer die Systemuhr, die die aktuelle Zeit für alle Prozesse bereitstellt.

Wenn die Synchronisation mit der Zeitreferenz nicht erfolgreich ist, läuft die Systemuhr einfach weiter.

Das automatische Auslesen der RTC erfolgt ausschließlich während des Bootvorgangs.

Natürlich.
Diese habe ich auch erläutert: Höhere Präzision und Zeitbezug bei fehlender Netzwerkanbindung, ggf. noch höhere Zuverlässigkeit bei schlechter Netzwerkanbindung.
Kein Zeitserver wird jedoch auf eine RTC verzichten. Ohne würde es einfach zu lange dauern, bevor nach einem Ausfall nach Reboot wieder eine korrekte Uhrzeit verfügbar wäre.

Ich glaube, dass hier Dein grundsätzliches Missverständnis liegt:
Die RTC soll nicht den NTP-Server oder eine andere Zeitquelle wie DFC77 zur Synchronisation mit einer Referenzzeit ersetzen.

Der Hauptzweck einer solchen Uhr ist folgender (aus den Linux manpages:)

The Hardware Clock's basic purpose is to keep time when Linux is not running so that the System Clock can be initialized from it at boot.

Das macht auch fake-hwclock (so gut es eben geht), aber eben ohne autonom weiterlaufende Uhr. Deswegen ist das ja auch ein fake und keine echte RTC - und damit dieser grundsätzlich unterlegen.

Ich vermute stark, dass die mangelhafte Dokumentation und möglicherweise auch die Softwareausstattung Deiner RTC massgeblich zu Deiner Fehleinschätzung von fake-hwclock als einer RTC überlegenen Lösung beigetragen haben.

Für zufällig vorbeikommende Leser fasse ich zusammen:

Der Einsatz eines RPi als Zeitserver ist bereits mit dem Standard-Betriebssystem möglich, sofern man die entsprechenden Pakete installiert hat. Es braucht dazu keine zusätzliche Hardware.
(Nominell ist dies - wie von Bordi erwähnt - ein NTP Stratum 3 oder sogar ein Stratum 2-Server (Zeitsignal(0) - öffentlicher NTP(1) - RPi(2))).

Wer auch nach längerem Abschalten des RPis (sei es beabsichtigt oder durch Stromausfall) sofort beim Neustart eine korrekte Uhrzeit verteilen will, gönnt seinem RPi ein Hardware-RTC-Modul für ein paar Euro (zzgl. Batterie). Dadurch ist ein RPi mit Pi-hole im Regelfall auch unmittelbar nach dem Start in der Lage, DNSSEC korrekt zu validieren (An dem Stratum ändert sich nichts).

Wer für einen RPi ohne Netzwerkanbindung auf eine verlässliche Zeit angewiesen ist und/oder eine präzise Zeitquelle benötigt, die über die mit NTP-Servern erreichbare Genauigkeit hinausgeht, kann die (u.U. deutlich) kostspieligere Anschaffung eines DCF77- oder GNSS-Empfängers in Betracht ziehen (wodurch Stratum 1 erreicht wird). Sofern dieser Empfänger nicht seinerseits bereits über eine Hardware-RTC verfügt, bleibt der Einsatz eines RTC-Moduls auch dann nach wie vor sinnvoll.

Coro · 1 July 2020 05:35

Ich habe damit schlechte Erfahrung gemacht, wegen genau was Du sagst, das die Zeit nach dem Neustarten manchmal Stunden daneben liegt. Bei uns fallen der Strom häufiger länger aus. Für Licht haben wir USV, kein Problem, Computer wollten wir verbinden, aber es gibt böse Stromspitzen, die müssen wir zuerst klären. Egal. Meine Tochter hat eine Spielekonsole. Wenn nach Stromausfall die Zeit am NTP nicht stimmen (nur wenn mehrere Stunden), dann diese oft abgestürzen. Das ist eine reproduzierbare Sache. Auch mit Windows 7 Computer meines Mannes gibt es Probleme. Daher...

Ich weiß nicht woher die Verwirrung oben gekommen ist, aber man kann das RTC Modul mit einem einfachen Befehl (nachdem das Raspberry die korrekte Zeit aus dem Internet geholt hat!) einstellen. Wie an der Armbanduhr mit dem Rädchen. Danach geht sie langfristig sehr genug (Abweichungen Sekunden pro Jahr).

Ich habe keine guten Erfahrungen mit DCF77 gemacht, aber das Signal ist an der Küste nicht stark. Ich habe jetzt tatsächlich GPS seit Mitte 2019 an meinem NTP Server. Das war nicht teuer und einfach. Es ist ein NEO-6M. Mit Antenne (direkt an dem Chip, nicht extern) hat es 10 Euro bei meine lokalen Elektromarkt gekostet. Ich habe es schon für Freunde bei Amazon empfohlen. Etwa für die gleiche Preis.

Tipp: Ich würde nicht eine extra für "Raspberry Pi" gelabelte GPS Empfänger kaufen. Eine einfache (5V Spannung aber beachten!) machen es genau so gut wenn man nur die vier Drähte per Hand verbindet.

Ich habe damit sehr sehr gute Erfahrung, die Pi-hole liegt unten im Keller am Fenster, hat immer einwandfrei GPS-Empfang durch die Fenster. Wir haben die beste Zeit in der ganzen Stadt

Bordi · 3 July 2020 09:38

Bestimmt meinst du:

Zeitzone auf Europa/Berlin:

sudo timedatectl set-timezone Europe/Berlin
sudo dpkg-reconfigure tzdata

Datum und Uhrzeit in einem Befehl setzen

sudo timedatectl set-time 2017-10-08 23:01

Die Hardware-Uhr anhand der Systemzeit einstellen

sudo hwclock --systohc

Für die lokale Zeit im eigenen Netz ideal. Wer jedoch einen eigenen Stratum 1/2/3 stellen möchte, und sich zur Weltzeit synchronisiert, hat ein kniffliges Problem zu lösen. Die RTC lässt sich einer Quarzuhr ähnlich nur von Hand einstellen. Bedeutet: Beim Setzen der Uhrzeit wird es Zwischen Bildschirm und Tastatur zu einer Verzögerung kommen die mindesten der Menschliche Reaktionszeit entspricht. Hinzu kommt der Unterschied zwischen der geeichten Weltzeit, und der Uhr von der man abgelesen hat.
NTP kann dies zwar ausgleichen, aber die RTC wird diesen Unterschied beibehalten. Bei einem Neustart nach einem Stromausfall kann es so dennoch zu einem Zeitlichen unterschied kommen. Mit unter kann der auch negativ, als der Weltzeit voraus sein.

Zugegeben, lokal ist das nicht so schlimm. Es kann aber durchaus dazu führen daß mit pool.ntp auf allen clients besser fährt, als mit dem lokalen Zeitserver. Den der braucht einige Tage bis er sich wieder an die Weltzeit angeglichen hat, oder schmeißt sogar ganz hin, wenn der unterschied zwischen unsynchronisierter Systemzeit (zB RTC), und der Synchronisierten Weltzeit-Uhr (zb GPS) zu groß ist.

Ich träume auch davon die Systemzeit Nanosekunden genau auf die Weltzeit abzustimmen, und diese zu nutzen um die RTC Verzögerungsfrei zu eichen.

ist mir bis jetzt nicht gelungen. Aber vielleicht hat ja wehr einen tipp?

Bucking_Horn · 3 July 2020 13:19

Die meisten Linux-Systeme schreiben während des Shutdowns die Systemzeit in die RTC. Ein entsprechend kompilierter Kernel tut dies sogar alle 11 Minuten.

Der menschliche Faktor lässt sich leicht aus der Kette eliminieren. Den korrekten Abgleich der Systemuhr mit einer Zeitreferenz erledigt ohnehin Dein (S)NTP-Client.
Ein manueller Eingriff in der von Dir beschriebenen Weise ist nur bei grösseren Abweichungen notwendig. Sobald Du die Differenz manuelll verkleinert hast, stellt ein erneuter Time-Sync die Übernahme der korrekten Uhrzeit sicher.

sudo hwclock --systohc schreibt die Uhrzeit aus der Systemuhr dann unmittelbar in die RTC.

Das Messen von Zeiträumen mit Nanosekunden-Genauigkeit ist in Abhängigkeit Deiner Hardware ggf. möglich. Das Setzen der Uhrzeit ist schon problematischer: Selbst zwischen Atomuhren muss man pro Tag eine Abweichung im Nanosekundenbereich hinnehmen, und empfangsbedingt ist hier mit weiteren Einschränkungen zu rechnen (ca. ~10ms mit NTP, ~100ms bis ~100 Mikrosekunden mit DCF77, noch genauer mit GNSS bei klarer Sicht in den Himmel).

Wenn es Dir darum geht, die RTC nicht nur beim Shutdown zu setzen:
Dein DS3231 sollte eine Abweichung im Bereich von ca. einer Sekunde pro Woche produzieren. Du könntest also theoretisch per cron alle ein oder zwei Wochen ein Setzen der Uhrzeit planen.

Generell würde ich das allerdings nicht uneingeschränkt empfehlen, denn so kann es im Ernstfall beim Auslesen der Uhrzeit aufgrund der automatischen Driftkorrektur u.U. zur Übernahme einer falschen Uhrzeit in die Systemuhr kommen.

Bei einem längeren Ausfall soll ja genau diese Driftkorrektur dafür sorgen, dass trotz der Ungenauigkeit der RTC beim erneuten Booten das System eine korrekte Uhrzeit erhält. Bei bekannter, halbwegs stabiler Drift ist daher ein Abgleich der RTC beim Shutdown völlig ausreichend.

mibere · 7 July 2020 22:26

Ich habe die folgenden Geräte (und eine RasClock als RTC), beide lassen sich am Raspi mit ntpd verwenden.

GNSS, Navilock NL-8002U

Vorteile

günstiger
GPS wenig störanfällig
weltweit verfügbar
Zeit recht schnell nach Systemstart verfügbar (je nach Satelliten)
Zeit ebenso genau wie bei DCF77, Genauigkeit evtl. sogar höher
Gerät auch verwendbar für Standort & Navigation

Nachteile

benötigt installierte Software (gpsd)
NL-8002U: kein PPS

DCF77, Gude Expert Mouse Clock 0107

Vorteile

benötigt keine Software (udev-Regel ausreichend)

Nachteile

teurer
DCF77 störanfällig, z.B. magnetische/elektrische/atmosphärische Störquellen
"nur" 2000km um Frankfurt verfügbar
Zeit erst nach 2-3 Minuten nach Systemstart verfügbar

Letztendlich habe ich mich dafür entschieden in ntpd den GNSS-Empfänger zu verwenden.
Die dafür gewählte Konfiguration in /etc/ntp.conf ist

server 127.127.46.0
fudge 127.127.46.0 time2 0.071

Der Vorteil vom Treiber 46 (verfügbar ab ntpd 4.2.8) gegenüber 28 ist, mit 46 kommunizieren gpsd und ntpd direkt miteinander.

Coro · 8 July 2020 12:05

Das dürfte dann den deutschsprachigen Raum abdecken. Wo diese Forum gelesen wird

Nein, das ist nicht wahr. Wurde aber schon gesagt:

Bordi · 10 July 2020 11:49

Danke für den aufschlussreichen Beitrag. Ich hätte da noch ein zwei kleine Fragen.

Du hast dich gegen u-blox 6 und u-blox NEO-M8U entschieden. Weshalb?
Wie ist der Indoor-Empfang so?

mibere · 10 July 2020 20:37

In der Wohnung habe ich Kontakt zu 12-16 Satelliten.

Das GNSS-Modul ist meiner Meinung nach egal, irgendeines mit GPS+GLONASS+EGNOS+NMEA0183. Zudem wäre mir eines wie bspw. das Navilock NL-82002U (mit NEO-M8U) zu teuer.

Ich wollte eines für USB haben - da ist die Herausforderung, eines zu finden, welches PPS unterstützt; und damit gibt es extrem wenige. Denn die Empfehlung ist, wenn GNSS für NTP, dann ausschließlich mit PPS. Und daraus ergibt sich die nächste Empfehlung: Verwendung des performance-Governors für die CPU. Und noch so ein paar andere Einstellungen, die man an der Systemkonfiguration ändern soll.

Kurzum: anstecken und nutzen, ist nicht. Nachdem ich mich nun mittlerweile mehrere Tage damit beschäftigt habe...lasst es, verschwendet eure Zeit nicht damit. Benutzt ntpd/chrony ohne externe Geräte.

Bordi · 11 July 2020 03:17

Zustimmung

stratum 2 hat man mit "pool time.nist.gov" o.ä. recht schnell.
stratum 1 ist da schon deutlich anspruchsvoller.

Einbindung ging bei mir recht gut. Ich hab jedoch Probleme mit der Stabilität von ntpd. Der schmiert gerne mal ab. Hauptproblem scheint die RTC zu sein, ob so ist muss sich noch herausstellen. Sicher ist das sie pro 24h gut 1Sec zurück hängt.