+-Serie DS 213+ RTC asynchron zur Systemzeit

[ottomane]

Nach einem Update war meine rtc.conf zuerst praktisch leer, dann habe ich eine Änderung in der Oberfläche gemacht und dann stand immerhin ein Timeserver drin. Aber eben nicht die RTC (127.127.1.0). Das habe ich soeben nachgetragen und werde heute mal testen.

 

[Puppetmaster]

So, geht doch: nur eine Zeile in der /etc/ntp.conf: server 127.127.1.0 prefer

 

[ottomane]

Danke! Wenn Du den ntpd nutzt, verlässt sich dieser alleine auf die Hardware-Uhr. Was aber immerhin besser ist, als meine Konfig

 

[Puppetmaster]

Danke! Wenn Du den ntpd nutzt, verlässt sich dieser alleine auf die Hardware-Uhr. Was aber immerhin besser ist, als meine Konfig

Den ntp-Dienst nutze ich aber nicht. Keine Veranlassung.
Daher habe ich schon eine ganz gute Zeitreferenz.

 

[ottomane]

Der ntp-Dienst kann zwei Aufgaben übernehmen: Die Zeit anderen zur Verfügung stellen (=Einstellung NTP-Dienst in der Oberfläche) und auch die Zeit der DS aktualisieren (= Einstellung Uhrzeit synchronisieren in der Oberfläche). Also nutzt man, selbst wenn man an der Oberfläche den NTP-Dienst deaktiviert, dennoch den ntpd. Und dieser nutzt die /etc/ntp.conf.

Diese Doppelfunktion erkennt man übrigens auch schön in folgendem Skript:

/usr/syno/etc/rc.d/S23ntpd.sh

if [ "$run_ntp_client" = "yes" -o "$run_ntp_server" = "yes" ]; then 
	RUNNTPD=1
fi

Es gibt eine weitere Möglichkeit, die Zeit zu aktualisieren: ntpdate in crontab eintragen. Davon ist aber abzuraten.

 

[Puppetmaster]

Ich habe mich bei "ntp-Dienst" an der Terminologie Synologys gehalten.
Damit meinte ich lediglich, daß ich den ntp-Server nicht nutze. Als Client sehr wohl, klar.

Was ich für mich nicht sehe ist der Sinn eines ntp-Servers auf der DS. Alle (relevanten) Netzwerkgeräte in meinem Netz holen sich die Zeit ja auch von einem externen Zeitserver.

 

[ottomane]

Ach so, war mir nicht klar, wie du das meintest. Anscheinend ist die RTC dann ja ganz gut.

 

[Benares]

Der ntpd läuft nur, wenn die DS als NTP-Client und/oder als NTP-Server konfiguriert ist (s. Script in #25). Ohne ntpd ist auch der Inhalt von /etc/ntp.conf egal. Es gibt aber noch einen Bug, den ich hier beschrieben habe.

Meines Wissen laufen Hard- und Software-Uhr bei Linux völlig asynchron. Beim Booten wird die Software-Uhr aus der Hardware-Uhr initialisiert. Danach wird die Software-Uhr meist beim Booten nochmal einmalig aus dem Internet aktualisiert (Option -g beim Start des ntpd) und anschliessend per ntpd auf einen Zeitserver im Internet "ausgeregelt". Oder (ohne ntpd) es wird per ntpdate-Cronjob von Zeit zu Zeit neu gesetzt. Zweiteres mögen aber nicht alle Programme, da die Zeit springt. Oder die Software-Uhr läuft halt frei und trifftet im Lauf der Zeit weg.
Die ntp-Synchronisation der Software- auf die Hardware-Uhr ist w.E. Quatsch und ist eher dafür gedacht, wenn eine Funkuhr angeschlossen ist, die die Hardware-Uhr synchronisiert. Das macht heute keiner mehr.

Die Frage ist nun, was die Software-Uhr bei der DS213 im Deepsleep macht. Läuft sie weiter? Bleibt sie stehen? Geht sie nach?
Vielleicht wird die Hardware-Uhr beim Übergang in den Deep-Sleep ja neu gesetzt und beim Aufwachen aus dieser geladen, wer weiss?
Das kann man m.E. nur rausfinden, wenn man sämtliche Synchronisationsmechanismen mal ausschaltet und das Ganze beobachtet.

Gruß Benares

 

[ottomane]

Meines Wissen laufen Hard- und Software-Uhr bei Linux völlig asynchron. Beim Booten wird die Software-Uhr aus der Hardware-Uhr initialisiert. Danach wird die Software-Uhr meist beim Booten nochmal einmalig aus dem Internet aktualisiert (Option -g beim Start des ntpd) und anschliessend per ntpd auf einen Zeitserver im Internet "ausgeregelt". Oder (ohne ntpd) es wird per ntpdate-Cronjob von Zeit zu Zeit neu gesetzt. Zweiteres mögen aber nicht alle Programme, da die Zeit springt. Oder die Software-Uhr läuft halt frei und trifftet im Lauf der Zeit weg.

Meinem Verständnis nach ist Letzteres falsch. Der ntpd aktualisiert regelmäßig seine Zeit aus dem Internet oder auch aus der RTC, wenn man das will. Aus diesen Informationen korrigiert er die Geschwindigkeit der laufenden Uhr.
Die Nutzung von ntpd und ntpdate als Client gleichzeitig funktioniert nicht. Wenn der ntpd läuft, führt ntpdate zu einem Socketfehler und bricht ab. Den Fehler sieht man nicht, wenn er im cronjob passiert. ntpdate sollte man nicht verwenden, da es Zeitsprünge ermöglicht und außerdem aus dem cronjob heraus die DS weckt (angeblich, habe ich nicht getestet). Der ntpd als Client alleine regelt eine falsch laufende Uhr sukzessive nach und müsste reichen. Die ntpdate-Sprünge will ich gerade an der NAS nicht haben, da z.B. so Backup-Zeitpunkte übersprungen werden können.

Die ntp-Synchronisation der Software- auf die Hardware-Uhr ist w.E. Quatsch und ist eher dafür gedacht, wenn eine Funkuhr angeschlossen ist, die die Hardware-Uhr synchronisiert. Das macht heute keiner mehr.

Die Frage ist nun, was die Software-Uhr bei der DS213 im Deepsleep macht. Läuft sie weiter? Bleibt sie stehen? Geht sie nach?
Vielleicht wird die Hardware-Uhr beim Übergang in den Deep-Sleep ja neu gesetzt und beim Aufwachen aus dieser geladen, wer weiss?
Das kann man m.E. nur rausfinden, wenn man sämtliche Synchronisationsmechanismen mal ausschaltet und das Ganze beobachtet.

Die Software-Uhr meiner DS bleibt im DS definitiv stehen. Sie geht danach genau um die Schlafzeit nach. Im Log erfolgen Einschlafen und Aufwachen nur Sekunden aufeinander, auch wenn der Schlaf Stunden gedauert hat. Leider habe ich im System noch keine Möglichkeit gefunden, beim Aufwachen einmalig die Softwarezeit sofort mit einem großen Sprung zu aktualisieren. Kennst Du ein Skript, was immer beim Aufwachen gerufen wird? Da würde soetwas hereingehören.

Leider wird im System keine korrekte Device auf die RTC gesetzt (noch ein Bug?), sodass man hwclock nicht benutzen kann, um die Harware mal auszulesen oder in die eine oder andere Richtung zu aktualisieren.

Viele Grüße
ottomane

 

[jahlives]

@ottomane
wegen dem Script. Hast du dir mal die PID des ntpd vor dem Schlaf und danach angeguckt und verglichen? Könnte mir gut vorstellen, dass u.U. ntpd nach dem Tiefschlaf eh neugestartet werden muss. Wenn sich die PID ändert, dann würde ich den Sync mit Sprung direkt im Startscript des ntp probieren. Sonst wüsste ich jetzt auch kein Script welches nach dem Tiefschlaf aufgerufen würde. Könnte mir aber gut vorstellen, dass User wie z.B. goetz oder itari hier vielleicht mehr wissen

 

[ottomane]

Danke für die Info, jahlives!

Es kam so, wie es kommen musste:

Die DS hat heute nacht wunderbar durchgeschlafen. Mit stehender Softwareuhr. Um 6:05 Uhr stand ein Backup auf dem Plan. Natürlich hat sie das verpennt. Zwar ist sie irgendwann heute morgen aufgewacht, aber das System hat seine Zeit dann auf 6:25 Uhr gestellt (was dann auch stimmte), aber damit den Backupzeitpunkt übersprungen.

Dagegen hilft dann leider auch kein Skript, das die Zeit sofort nach dem Aufwachen korrigiert.

Ich bin ratlos. Dieses Problem ist so nicht in den Griff zu bekommen. Nur ein Update kann da helfen. Ich frage mich nur: Bin ich eigentlich der einzige, bei dem die Uhr stehenbleibt? Das müsste doch bei jedem auftreten und fatale Folgen bei geschedulten Jobs haben?

Die einzig denkbare Lösung für ein Update, die mir einfällt ist die, dass künftig alle zeitgesteuerten Jobs anhand der RTC laufen. Ich habe Zweifel, dass das überhaupt möglich ist, es ist wahrscheinlich, dass mit der RTC nur ein Einschalten geht.
Eine Zeitsteuerung anhand der Softwarezeit ist grundätzlich nicht sinnvoll möglich, da im DeepSleep die CPU heruntergefahren wird und damit konzeptionell gar kein Zählen der Softwarezeit möglich ist. Da hat Synology noch nette Hausaufgaben zu lösen. Ich habe DeepSleep wieder aus. Es kann so einfach nicht 100% sauber funktionieren, da es konzeptionell nicht zu Ende gedacht ist. Ich bin gespannt, was sich Synology da ausdenkt - schöne Ecke, in die die Entwickler vom Marketing gedrängt wurden, könnte man meinen.

 

[Benares]

Meinem Verständnis nach ist Letzteres falsch...

Ich meinte damit den Betrieb ganz ohne Zeitsysnchronisation, also ohne ntpd.
Hast du das eigentlich mal probiert? Geht dann die Uhr nach dem Deep Sleep wirklich jedesmal um die Deep-Sleep-Dauer nach?

Ansonsten hast du Recht, der Deep Sleep ist noch nicht ausgereift. Ich würd ihn auch erstmal abschalten und auf das nächste Update warten (wenn ich eine 213 hätte).

Gruß Benares

 

[ottomane]

Natürlich, das hattest Du ja auch geschrieben. Ich hätte es nur genauer lesen müssen

Ohne ntpd hatte ich schon, ja. Der Effekt ist der selbe, nur dass sich die Uhr nie mehr korrigiert.

 

[Frogman]

Um 6:05 Uhr stand ein Backup auf dem Plan. Natürlich hat sie das verpennt. Zwar ist sie irgendwann heute morgen aufgewacht, aber das System hat seine Zeit dann auf 6:25 Uhr gestellt (was dann auch stimmte), aber damit den Backupzeitpunkt übersprungen.

Warum ist sie denn um 6:25 Uhr aufgewacht - stand da noch etwas anderes an als das Backup? Wenn der Aufwachgrund das geplante Backup gewesen sein sollte, würde das nur bedeuten, dass die Box gute 20 Minuten zu spät dran war. Da ich jetzt nicht glaube, dass die Box in der gesamten Nacht nur 20 Minuten im Deep-Standby war, klingt es eher wahrscheinlich, dass die RTC in Deiner Box ein sehr schelchtes Exemplar ist - eventuell auch ein Hinweis darauf, dass sich hier nicht massenweise Leute mit dem Problem melden.

 

[ottomane]

Ich weiß nicht, warum sie aufgewacht ist. Möglicherweise kam da was über das WLAN rein, das sich um 6:00 Uhr einschaltet (oder der Router macht da irgendwas).

Es war nicht das Backup, was die DS aufgeweckt hat, denn es wurde weder eines gemacht noch wurde ein Fehler gemeldet. Ich habe das mal im Log markiert. Die DS meldet ja selbst eine Zeitabweichung von 461 Minuten.

Ich glaube nicht, dass es die RTC ist, die spinnt. Ein Ein-/Ausschalten nach Plan funktioniert perfekt. Ich denke, die Backups werden über die Softwarezeit getriggert.

Nov 28 21:32:36 kernel: [34359.761760] Got empty serial number. Generate serial number from product.
Nov 28 21:32:36 scemd: SCEMD: disk 1 wake up from hibernation
Nov 28 21:32:36 scemd: modules/disk_hibernation.c:2040 Diskstation wakes up from deep sleep.
Nov 28 21:32:37 scemd: SCEMD: disk 2 wake up from hibernation
Nov 28 21:32:37 scemd: modules/fan_check_common.c:601 Start fan full speed to avoid fan fail
Nov 28 21:32:37 scemd: SCEMD: disk 4 wake up from hibernation
Nov 28 21:32:43 scemd: modules/fan_check_common.c:605 Stop fan full speed to avoid fan fail
Nov 28 22:33:53 kernel: [37123.485439] Freezing user space processes ... (elapsed 0.00 seconds) done.
Nov 28 22:33:53 kernel: [37123.493071] Freezing remaining freezable tasks ... (elapsed 0.03 seconds) done.
Nov 28 22:33:53 kernel: [37123.531455] Suspending console(s) (use no_console_suspend to debug)
Nov 28 22:33:53 kernel: [37123.539045] ata4: send port disabled event
Nov 28 22:33:53 kernel: [37123.558318] ata3: send port disabled event
Nov 28 22:33:53 kernel: [37123.760981] ata1: send port disabled event
Nov 28 22:33:53 kernel: [37123.761027] ata2: send port disabled event
Nov 28 22:33:53 kernel: [37123.785829] Disabling non-boot CPUs ...
<<< hier ist die DS eingeschlafen, die Uhr steht
####################################################################################################
jetzt wacht sie wieder auf, in Wirklichkeit ist es Stunden später (siehe Zeitkorrektur weiter unten)>>>
Nov 28 22:33:53 kernel: [37124.300914] Enabling non-boot CPUs ...
Nov 28 22:33:53 kernel: [37124.300943] setting frequency for cpu 0 to 1066666 kHz, PLL ratio is 4/2
Nov 28 22:33:53 kernel: [37124.300951] PMJCR request 04043c00 at CPU 0
Nov 28 22:33:53 kernel: [37124.300957] PORPLLSR core freq 1066MHz at CPU 0
Nov 28 22:33:53 kernel: [37124.344967] Processor 1 found.
Nov 28 22:33:53 kernel: [37124.455700] 0: 533333kHz
Nov 28 22:33:53 kernel: [37124.455704] 1: 799999kHz
Nov 28 22:33:53 kernel: [37124.455708] 2: 1066666kHz
Nov 28 22:33:53 kernel: [37124.455712] 3: 1333332kHz
Nov 28 22:33:53 kernel: [37124.455715] 4: 1599999kHz
Nov 28 22:33:53 kernel: [37124.455719] 5: 1866665kHz
Nov 28 22:33:53 kernel: [37124.455722] 6: 2133332kHz
Nov 28 22:33:53 kernel: [37124.455768] setting frequency for cpu 1 to 1066666 kHz, PLL ratio is 4/2
Nov 28 22:33:53 kernel: [37124.455774] PMJCR request 04043c00 at CPU 1
Nov 28 22:33:53 kernel: [37124.455779] PORPLLSR core freq 1066MHz at CPU 1
Nov 28 22:33:53 kernel: [37124.455813] setting frequency for cpu 1 to 1066666 kHz, PLL ratio is 4/2
Nov 28 22:33:53 kernel: [37124.455819] PMJCR request 04043c00 at CPU 1
Nov 28 22:33:53 kernel: [37124.455824] PORPLLSR core freq 1066MHz at CPU 1
Nov 28 22:33:53 kernel: [37124.455829] CPU1 is up
Nov 28 22:33:53 kernel: [37124.967328] ata3: No Device OR PHYRDY change,Hstatus = 0xa0000000
Nov 28 22:33:53 kernel: [37134.458593] ata2: softreset failed (timeout)
Nov 28 22:33:53 kernel: [37134.458599] ata2: softreset failed, set srst fail flag
Nov 28 22:33:53 kernel: [37134.458623] ata1: softreset failed (timeout)
Nov 28 22:33:53 kernel: [37134.458627] ata1: softreset failed, set srst fail flag
Nov 28 22:33:53 kernel: [37136.657523] ata2: link reset sucessfully clear error flags
Nov 28 22:33:53 kernel: [37137.105298] ata1: link reset sucessfully clear error flags
Nov 28 22:33:53 kernel: [37146.804892] Restarting tasks ... done.
Nov 28 22:33:54 kernel: [37147.521520] usb usb2: No SuperSpeed endpoint companion for config 1  interface 0 altsetting 0 ep 129: using minimum values
Nov 28 22:33:54 kernel: [37147.679140] Got empty serial number. Generate serial number from product.
Nov 28 22:33:55 scemd: SCEMD: disk 1 wake up from hibernation
Nov 28 22:33:55 scemd: modules/disk_hibernation.c:2040 Diskstation wakes up from deep sleep.
Nov 28 22:33:55 scemd: SCEMD: disk 2 wake up from hibernation
Nov 28 22:33:55 scemd: modules/fan_check_common.c:601 Start fan full speed to avoid fan fail
Nov 28 22:33:55 scemd: SCEMD: disk 4 wake up from hibernation
Nov 28 22:34:01 scemd: modules/fan_check_common.c:605 Stop fan full speed to avoid fan fail
Nov 28 22:44:39 scemd: modules/rtc.c:188 RTC and system time diff are too large. rtc_year:[112] rtc_mon:[10] rtc_mday:[29] rtc_hour:[5] sys_year:[112] sys_mon:[10] sys_mday:[28] sys_hour:[21] timezone:[-3600]
Nov 28 22:44:43 scemd: modules/rtc.c:188 RTC and system time diff are too large. rtc_year:[112] rtc_mon:[10] rtc_mday:[29] rtc_hour:[5] sys_year:[112] sys_mon:[10] sys_mday:[28] sys_hour:[21] timezone:[-3600]
Nov 28 22:44:43 scemd: modules/rtc.c:206 RTC looks like fine, maybe system error let it update
Nov 29 06:25:30 crond[5590]: crond: time disparity of 461 minutes detected
Nov 29 06:25:35 scemd: SCEMD: disk 1 wake up from hibernation
Nov 29 06:25:52 scemd: SCEMD: disk 2 wake up from hibernation
Nov 29 06:36:37 scemd: SCEMD: disk 4 wake up from hibernation

 

[Frogman]

Ein Ein-/Ausschalten nach Plan funktioniert perfekt.

Das ist ja dann eine durchaus wichtige Info - dann stimme ich Dir auch zu in Bezug auf die RTC.

 

[süno42]

Die Ursache für die asynchrone Systemzeit ist ganz einfach zu erklären. Die Diskstation sowie jeder PC (ab AT) besitzen eine Echtzeituhr (RTC = Real Time Clock), die als einzige bei ausgeschaltetem Gerät weiterläuft. Diese Uhr wird bei ausgeschaltetem Gerät durch eine Pufferbatterie gespeist (Knopfzelle, bei alten Computern auch fest auf der Hauptplatine verlötet). Die Echtzeituhr beinhaltet auf PCs auch das sogenannte CMOS-Ram für die Einstellungen des Systembios (bei neueren PCs einen Teil der BIOS-Einstellungen).

Vom kurzen Ausflug zurück zur eigentlichen Sache:
Nach dem Systemstart simuliert das Betriebssystem eine Systemuhr in Software, die durch einen Hardware-Zeitgeber (nicht zu verwechseln mit der RTC) gespeist wird. Da der Zustand des Betriebssystems beim Systemruhezustand eingefroren wird, läuft logischerweise auch die Systemuhr nicht weiter. Nach dem Aufwachen aus dem Systemruhezustand läuft die Systemuhr genau an der Stelle weiter, an der sie beim Einfrieren des Systemzustandes stehengeblieben ist. Deshalb muß die Systemuhr unverzüglich mit einer Referenzzeitquelle synchronisiert werden, was zunächst die Echtzeituhr ist (die Systemuhr wird folglich immer vorgestellt). Daher resultieret nach dem Aufwachen aus dem Systemruhezustand die verwirrende Meldung im Systemlog.

Die resultierenden Seiteneffekte, daß der cron-Dämon seine Time-Backup-Aufträge nicht ausführt, ist ein Softwarebug und hat zunächst einmal nichts mit NTP zu tun. Die Ursache scheint aber in der Zeitsynchronisation zu liegen.

 

[ottomane]

Ja, das meine ich ja auch, zumindest ist mir das nach und nach klar geworden.

Ich habe allerdings die Vermutung, dass es mehr ist als ein Software-Bug. Ich vermute, dass per RTC im Sleep grundsätzlich gar kein Backup getriggert werden kann. Wie auch, wenn der Rest der Hardware schläft. Das Timer-gesteuerte An/aus der DS ist eine Hardwarefunktion - mehr geht da m.E. nicht.

 

[Puppetmaster]

Ich habe allerdings die Vermutung, dass es mehr ist als ein Software-Bug. Ich vermute, dass per RTC im Sleep grundsätzlich gar kein Backup getriggert werden kann. Wie auch, wenn der Rest der Hardware schläft. Das Timer-gesteuerte An/aus der DS ist eine Hardwarefunktion - mehr geht da m.E. nicht.

Also ich kann da nur nochmal erwähnen, daß das Aufwachen zur Backupzeit aus dem deep-sleep bei mir funktioniert. Habe jetzt in den letzten beiden Tagen extra mal ein paar Backupjobs angelegt: die DS wacht ca. 1 Minute vor der geplanten Zeit auf und startet danach den Job. Warum sollte das auch nicht üder die Hardware-Uhr gesteuert werden können?

 

[Hero58]

Bin seit einer Woche auch stolzer Besitzer einer DS213+.
Also bei meiner DS ist es genau so, dass beim erweiterten Ruhezustand die Uhr hinterher falsch geht. Aber nur, wenn in den Optionen "mit einem NTP-Server synchronisieren" aktiv ist. Das Ausschalten nach Plan wurde dadurch nicht zur eingestellten Uhrzeit ausgeführt. Bei Manuell läuft die Uhr weiter.