RTC des HAT

[remotecontrol]

Hallo TF-Team,

ich habe ein paar Detailfragen zur Funktion der RTC des HAT:

• in der Doku steht "mit Batteriebackup"
  => puffert der HAT die Zeit ohne zusätzliche externe Batterie?
• Der Raspi war einen Tag aus, kurz nach booten des Raspi wird die Zeit "schnell hochgezählt" bis die tatsächliche aktuelle Zeit erreicht wird.
  Ich habe eine Schleife in meinem Programm welches eigentlich nur 1x pro Sekunde aktiv wird und man sieht deutlich, dass es sehr schnell was tut. Eine Uhr zählt mehrere Minuten im Sekundentakt hoch, bis die aktuelle Zeit erreicht wird.
  => kommt das über den brickd mit der RTC oder macht der Raspi das quasi immer so?

Ich frage mich nämlich wie ich diesen initialen Zustand erkennen kann?

Programmseitig sieht das nämlich so aus, als kämen über eine Stunde keine Events vom Stack und das Programm denkt "das System reagiert nicht mehr".
Dabei sind in realer Zeit ja mal gerade 10 Sekunden vergangen.

Eine Variante wäre noch, /dev/rtc (hwclock) mit der Systemzeit zu vergleichen und zwar so lange, bis die wenigstens auf 1 Minute bei einander sind und dann erst richtig zu starten.

[photron]

Die Doku ist da etwas ungenau, das ist ein Super-Cap, keine Batterie. Leider hält der auf der aktuellen HAT Version 1.4 nicht besonders lange vor, bedingt durch den zu großen Leckstrom einer Diode. Das Problem ist auf der nächsten Hat Version 1.5 behoben.

Es sollte eigentlich folgendes passieren: Das Raspberry Pi erkennt den HAT Brick und lädt den Kernel Treiber für den RTC Chip PCF8523. Der Kernel führt aber kein hwclock --hctosys aus, um die Systemzeit von der RTC Zeit zu setzen, dazu müsste der Kernel mit CONFIG_RTC_HCTOSYS=y gebaut sein, was bei Raspbian aber nicht der Fall ist. Jetzt lädt der Kernel das Userland und systemd startet brickd. Brick Daemon erkennt, dass der HAT Brick angeschlossen ist und führt jetzt hwclock --hctosys aus, dass die Hardware Clock (hc) liest (den RTC Chip) und damit die System Clock (sys) setzt. Das sollte die Systemzeit auf die RTC Zeit springen lassen, aber nur wenn der Super-Cap durchgehalten hat.

In das ganze kann jetzt auch noch fake-hwclock mit hineinspielen. Teste mal, ob sich das Verhalten ändert, wenn du fake-hwlock deinstallierst.

Normalerweise läuft Zeitsynchronisation auf Linux so, dass am Anfang einmal die Systemzeit auf die richtige Zeit springt (z.B. per NTP oder RTC) und danach, z.B. durch NTP die Systemzeit ständig nachkorrigiert wird. Diese Nachkorrigieren wird dann durch Strecken und Stauchen von Sekunden gemacht, damit die Systemzeit monoton ist und nicht springt.

Was mich wundert ist das schnelle hochzählen, das ist nicht normal. Welche Kernel Version hast du laufen?

Du kannst auch mal testen einen richtigen NTP Dienst zu installieren (z.B. chrony) anstelle dieser Krücke systemd-timesyncd die standardmäßig läuft.

[remotecontrol]

Mit NTP und Ethernetverbindung beim Booten tritt das Problem nicht mehr auf.
Das NTP gar nicht installiert war ist mir nicht aufgefallen, dachte jede Distro installiert das mit ... nutze das Standard Raspbian.

Die fake-hwclock habe ich mal deinstalliert.

[photron]

systemd-timesyncd als NTP Client ist normalerweise installiert und ist eigentlich auch bei Raspbian dabei. Aber systemd-timesyncd ist eine simple minimale SNTP Implementierung. Das reicht für viele Zwecke. Aber ich habe auch schon festgestellt, dass systemd-timesyncd absolute nicht damit klar kommt, wenn die Internetverbindung schlecht ist, dann kommt keine sinnvolle Zeitsynchronisierung zustande. Für ntpd und chronyd ist das aber kein Problem.

Interessant, wäre trotzdem zu sehen was passiert, wenn du alle NTP Dienste deaktivierst, damit zu erkennen ist, was die RTC da wirklich tut, denn wenn du NTP laufen hast, dann überstimmt das die RTC in jedem Fall.

[remotecontrol]

OK versuche ich bei Gelegenheit. Wie lange puffert die RTC im HAT denn ca. die Zeit?

Ich muss den PI ja min. 12h Stunden aus lassen damit beim Neustart die Zeit sichtlich hoch geht und der Vorgang lange genug dauert.

[remotecontrol]

Hatte den PI jetzt 3 Tage aus

• Nach Neustart war das Datum 14. Februar 2019
• Nach einer Weile (~ 30 Sekunden) fing die Zeit an, langsam hochzuzählen, das wurde dann schneller bis die aktuelle Zeit erreicht wurde
• der ganze Vorgang ging ca. über 2 Minuten

Sieht für mich so aus, als verliert die RTC im HAT die Zeit und der NTP braucht einfach eine Weile bis die korrekte Zeit im System eingestellt ist.
Das Hochzählen scheint mit systemd-timesynd und NTP ähnlich zu sein.

Ist der PI nur ein paar Stunden aus, so ist die Zeit quasi nach Booten sofort korrekt.