+-Serie DS 213+ RTC asynchron zur Systemzeit

[ottomane]

@Puppetmaster, hero58: Danke für die Infos! Bedes könnte ein Hinweis darauf sein, dass, wenn man den ntpd gar nicht nutzt, die Zeitprobeme nicht so auftreten (Zeit läuft weiter bei "manuell", Backup-Jobs werden ausgeführt).

Scheint so, als ob ich da noch mal eine Runde testen muss

 

[Puppetmaster]

@Puppetmaster, hero58: Danke für die Infos! Bedes könnte ein Hinweis darauf sein, dass, wenn man den ntpd gar nicht nutzt, die Zeitprobeme nicht so auftreten (Zeit läuft weiter bei "manuell", Backup-Jobs werden ausgeführt).

Scheint so, als ob ich da noch mal eine Runde testen muss

Na, was heißt 'gar nicht', ich habe immerhin eingestellt, daß die DS sich automatisch die Zeit holt. Zumindest ist die Option bei mir angehakt, ob sie das wirklich tut weiß ich allerdings nicht.

 

[ottomane]

Oh, peinlich, das Thema hatten wir ja kürzlich. Du meintest das, was Synology als ntp-Dienst bezeichnet. Stimmt ja. Du nutzt ihn, aber er liest nur die RTC.

 

[süno42]

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.

Das ist in der Regel kein Problem. Beim PC läßt sich in der Echtzeituhr eine Alarmzeit programmieren, die dann den PC startet. Genauso funktioniert das auch auf der Synology.

 

[ottomane]

Das meine ich ja auch: Die DS lässt sich wie ein PC per RTC an/ausschalten. Aber wie beim PC kann man nicht per RTC aus dem Sleepmodus heraus irgendein Skript starten. Aber wie gesagt, das ist nur eine Vermutung.

Ein bisschen was an Doku zur Plattform findet man übrigens hier: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=P1022

 

[itari]

bislang*) war das Aufwecken per Uhr(zeit) immer mit einem neuen Boot verbunden, da es ja nicht wirklich ein 'Hibernate' (RAM -> Platte) gibt. Wer sich ein wenig mit Linux auskennt, kann natürlich bei jedem Boot auch Skripte aufrufen, die spezielle Dinge tun (/usr/syno/etc/rc.d/) oder halt die Uhr mit dem crontab-Einträgen so geschickt verzahnen, dass dies passt


*) bislang bedeutet, dass ich keine neue Modelle hab, um nachzuschauen, ob sich daran etwas geändert haben könnte

Itari

 

[ottomane]

Ich habe mal ein wenig in der Plattform-Beschreibung herumgewühlt. Laut Freescale ist es ausdrücklich so, dass der WakeUp aus dem DeepSleep durch einen programmierbaren Timer möglich ist. Da muss ich meiner eigenen Vermutung also erst einmal widersprechen.

Also: Möglich ja, ob es funktioniert, ist was anderes

 

[Puppetmaster]

Laut Freescale ist es ausdrücklich so, dass der WakeUp aus dem DeepSleep durch einen programmierbaren Timer möglich ist. Da muss ich meiner eigenen Vermutung also erst einmal widersprechen.

Wenn dem nicht so wäre, dann hätte Synology sich aber nicht nur ins Knie geschossen wenn sie ein System auf den Markt werfen würden, daß von der Hardware aus schon gar nicht in der Lage ist, ein geplantes Backup sicher durchzuführen.

 

[ottomane]

Ja, allerdings. Ich kann mir aber nun sehr gut vorstellen, wie viele graue Haare die Entwickler der DS bekommen haben bzw. weiter bekommen. Das Reference Manual umfasst ca. 1900 Seiten, komprimiert gefüllt mit technischen Details. Ein nicht geringer Anteil befasst sich dabei mit den verschiedenen Energiesparmodi (doze, nap, sleep, deep sleep, lossless deep sleep), wie die konfiguriert werden und wie man da wieder heraus kommt.

 

[Puppetmaster]

Ich sagte ja schon: ich beobachte das weiter mit Spannung. Ich finde die Entwicklung interessant. Leider verärgert Synology derweil viele neue Anwender, indem eine halbgare Softwareunterstützung zum Produkt geliefert wird.

 

[süno42]

Das meine ich ja auch: Die DS lässt sich wie ein PC per RTC an/ausschalten. Aber wie beim PC kann man nicht per RTC aus dem Sleepmodus heraus irgendein Skript starten. Aber wie gesagt, das ist nur eine Vermutung.

Ein bisschen was an Doku zur Plattform findet man übrigens hier: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=P1022

Jetzt ohne die Doku gelesen zu haben, behaupte ich mal, daß selbst dies technisch möglich ist. Denn normalerweise kann das System den Verursacher eines Einschaltereignisses abfragen. Ob dies so gemacht wird, ist eine andere Frage.

 

[ottomane]

Das verstehe ich nicht. Wer soll denn der Verursacher des Einschaltereignisses sein? Da alles andere schläft, kann das nur die RTC sein. Das Backup-Skript wird das wohl nicht sein, da das gerade steht.

Aber wie oben gesagt: Es gibt einen programmierbaren Timer, der den DeepSleep beenden kann. Beim Start des DeepSleep müsste die Software nur nachsehen, wie lange es bis zum nächsten Job noch hin ist und den Timer auf diesen Wert setzen (besser ein wenig früher).

Das funktioniert leider aber nicht. Habe das nun mehrere Tage getestet. Backups werden reproduzierbar verpennt. Was die Zeitkorrektur nach dem DeepSleep betrifft, hilft es tatsächlich, die Zeiteinstellung auf manuell zu setzen, also gar kein ntpd zu verwenden. Dadurch korrigiert er die Softwarezeit sofort nach dem Aufwachen auf die RTC. Immerhin.

 

[süno42]

Das verstehe ich nicht. Wer soll denn der Verursacher des Einschaltereignisses sein? Da alles andere schläft, kann das nur die RTC sein. Das Backup-Skript wird das wohl nicht sein, da das gerade steht.

Mit Verursacher meine ich die Hardwarekomponente, die für das Aufwachen aus dem Systemruhezustand verantwortlich ist. Da gibt es natürlich mehrere, z.B.

• Echtzeituhr/Timerbaustein
• Ein-/Auschschalt-Taster
• USB-Ereignis (z.B. Ein/Ausstecken eines Gerätes, …)
• Ein/Ausstecken einer SD-Karte (nicht getestet, ob die Diskstation dies registriert und hier auch aufwacht. Also reine Spekulation)

auf dem Standard-PC noch

• diverse PCI-Engeräte
• serielle Schnittstelle
• usw.

 

[henne10]

Das Problem scheint hier ja noch nicht wirklich gelöst zu sein, wenn ich das alles richtig verstanden habe.

Ich habe genau das gleiche Problem. Meine Systemzeit bleibt stehen sobald die DS213+ in den deepsleep geht.

z.B.

Feb  2 13:16:55 ntpdate: Sync with time server 213.172.105.106 offset 69960.455568 sec.
Feb  2 13:17:02 crond[5884]: crond: time disparity of 1167 minutes detected

Den Sync habe ich manuell in den Region Einstellungen durchgeführt.
In der CronTab steht nichts Relevantes drin was die Zeitsteuerung beeinflusst.


Meine DS geht Montags - Freitags um 22:30 Uhr schlafen und wacht gegen 16:30 Uhr wieder auf. Am Wochenende läuft sie durch.
Nach 20 Miunten darf sie dann in den deepsleep.

Wie könnte man das Problem nun am besten beheben, da der Sync ja immer gegen 24 Uhr passiert?
Ich habe in der synoinfo.conf den Parameter

ntpdate_period="daily"

gefunden könnte man das darüber vielleicht steuern?

 

[dave82]

Hi,

ich muss diesen Thread leider wieder zum Leben erwecken

Ich habe seit paar Tagen eine gebrauchte DS213+ gekauft und mir ist jetzt auch aufgefallen, dass bei einem System-Standby die Uhrzeit stehen bleibt. Kurz nach dem Aufwecken ist die Zeit wieder synchron. Egal wann ich die DS aufwecke, in den Logfiles erscheinen immer folgende Einträge:

Mar 23 04:38:27 nasbackup scemd: event_sync_systime_with_rtc.c:152 RTC looks like fine, maybe system error let it update
Mar 23 15:17:43 nasbackup scemd: event_sync_systime_with_rtc.c:134 RTC and system time diff are too large. rtc_year:[115] rtc_mon:[2] rtc_mday:[24] rtc_hour:[3] sys_year:[115] sys_mon:[2] sys_mday:[23] sys_hour:[14] timezone:[-3600]
Mar 23 15:17:47 nasbackup scemd: event_sync_systime_with_rtc.c:134 RTC and system time diff are too large. rtc_year:[115] rtc_mon:[2] rtc_mday:[24] rtc_hour:[3] sys_year:[115] sys_mon:[2] sys_mday:[23] sys_hour:[14] timezone:[-3600]
Mar 23 15:17:47 nasbackup scemd: event_sync_systime_with_rtc.c:152 RTC looks like fine, maybe system error let it update
Mar 24 04:39:34 nasbackup scemd: event_sync_systime_with_rtc.c:134 RTC and system time diff are too large. rtc_year:[115] rtc_mon:[2] rtc_mday:[25] rtc_hour:[3] sys_year:[115] sys_mon:[2] sys_mday:[24] sys_hour:[3] timezone:[-3600]
Mar 24 04:39:38 nasbackup scemd: event_sync_systime_with_rtc.c:134 RTC and system time diff are too large. rtc_year:[115] rtc_mon:[2] rtc_mday:[25] rtc_hour:[3] sys_year:[115] sys_mon:[2] sys_mday:[24] sys_hour:[3] timezone:[-3600]
Mar 24 04:39:38 nasbackup scemd: event_sync_systime_with_rtc.c:152 RTC looks like fine, maybe system error let it update
Mar 25 04:38:23 nasbackup scemd: event_sync_systime_with_rtc.c:134 RTC and system time diff are too large. rtc_year:[115] rtc_mon:[2] rtc_mday:[25] rtc_hour:[8] sys_year:[115] sys_mon:[2] sys_mday:[25] sys_hour:[3] timezone:[-3600]
Mar 25 04:38:27 nasbackup scemd: event_sync_systime_with_rtc.c:134 RTC and system time diff are too large. rtc_year:[115] rtc_mon:[2] rtc_mday:[25] rtc_hour:[8] sys_year:[115] sys_mon:[2] sys_mday:[25] sys_hour:[3] timezone:[-3600]
Mar 25 04:38:27 nasbackup scemd: event_sync_systime_with_rtc.c:152 RTC looks like fine, maybe system error let it update

Mir stellt sich nun die Frage ob die RTC meiner Defekt ist, da ein hwclock auf der DS213+ folgendes Ergebnis liefert:

nasbackup> hwclock
hwclock: can't open '/dev/misc/rtc': No such device

Zum Vergleich auf der DS415+

nas> hwclock
Wed Mar 25 09:36:09 2015  0.000000 seconds

Auch ist das Verzeichnis /proc/driver/ leer, auf der DS415+ liegt dort ein File "rtc" mit folgendem Inhalt:

nas> cat /proc/driver/rtc
rtc_time        : 09:37:05
rtc_date        : 2015-03-25
alrm_time       : 00:00:00
alrm_date       : 2015-03-03
alarm_IRQ       : no
alrm_pending    : no
update IRQ enabled      : no
periodic IRQ enabled    : no
periodic IRQ frequency  : 1024
max user IRQ frequency  : 64
24hr            : yes
periodic_IRQ    : no
update_IRQ      : no
HPET_emulated   : yes
BCD             : yes
DST_enable      : no
periodic_freq   : 1024
batt_status     : okay

Ich vermute, da ich die DS213+ als Backupmaschine nutzen wollte, dass Backupjobs dann nicht korrekt ausgeführt werden können. Als Lösung bleibt dann wohl nur den System-Sleep zu deaktiveren und die DS 24/7 durchlaufen zu lassen

Letztendlich ist das nicht so schlimm, mich würde aber interessieren, ob das bei den Anderen DS213+ Besitzern auch der Fall ist, dass die RTC nicht ausgelesen werden kann, bzw. gibt es Besitzer wo hwclock eine Ausgabe liefert?

Gruß Dave

 

[dil88]

Könnte es sein, dass die Stützbatterie alle ist?

 

[dave82]

Könnte es sein, dass die Stützbatterie alle ist?

Hi dil88,

ja es könnte sein, das habe ich noch nicht getestet. Wenn ich mal die Zeit finde, nehme ich die DS213+ auseinander und tausche die Knopfzelle.

Ich habe den Thread gelesen und es scheint sich nicht um einen Einzelfall zu handeln, um so mehr würde es mich wundern, wenn es "nur" die Batterie wäre.

Danke nochmal für den Tipp!

Gruß Dave

 

[ottomane]

Hallo,

ich habe das mal bei meiner ds 213+ ausprobiert und erhalte die selbe Fehlermeldung:

hwclock
hwclock: can't open '/dev/misc/rtc': No such file or directory

Ich würde davon ausgehen, dass, sofern nur die Batterie leer wäre, es trotzdem die Device im Verzeichnisbaum gäbe. Aber bei mir fehlt sogar das Verzeichnis /dev/misc/.