RTC einbauen
-
- Tuxboxer
- Beiträge: 2331
- Registriert: Donnerstag 24. März 2005, 21:52
-
- Interessierter
- Beiträge: 46
- Registriert: Sonntag 22. August 2004, 16:31
@Gorcon:
Auszug aus dem WIKI:
@all:
Ich werde mich demnächst nochmal dranmachen und dem sectionsd wie vorgeschlagen (Dank an houdini und ChakaZulu) einen weiteren Kommandozeilenparameter verpassen. Sowas wie "-tc" für "time correct" oder so ähnlich.
Das sollte in der Tat die meisten Möglichkeiten bieten. Denn dann kann der zyklische Zeitabgleich wie bisher wahlweise über DVB bzw. NTP (je nachdem ob man die Box im Netz hat oder nicht) erfolgen und falls es in Zukunft noch mehr geben sollte als die RTC kann der Kommandozeilenparameter ebenfalls genutzt werden.
Das restliche RTC-Handling (setzen der Systemzeit beim Hochfahren und das Speichern vor dem Runterfahren) erfolgte bisher ja auch ausserhalb des sectionsd also ganz nach dem Motto:
heisly
Das ist die Standard-Vorgehensweise beim Einbinden der RTC, wie sie auch im aktuellen JtG-Snap bereits implementiert ist. Beim Herunterfahren wird die Zeit zwar nicht mehr explizit auselesen, aber die Systemzeit, die ja zyklisch aktualisiert wird (DVB bzw. NTP), wird in der RTC abgespeichert... beim runterfahren nocheinmal die Uhrzeit aus dem EPG ausliest und damit die RTC bei bedarf korrigiert?
Auszug aus dem WIKI:
Code: Alles auswählen
in /etc/init.d/halt folgendes einfügen:
if [ -e /var/etc/.rtc ]; then
/bin/hwrtc systohw
fi
@all:
Ich werde mich demnächst nochmal dranmachen und dem sectionsd wie vorgeschlagen (Dank an houdini und ChakaZulu) einen weiteren Kommandozeilenparameter verpassen. Sowas wie "-tc" für "time correct" oder so ähnlich.
Das sollte in der Tat die meisten Möglichkeiten bieten. Denn dann kann der zyklische Zeitabgleich wie bisher wahlweise über DVB bzw. NTP (je nachdem ob man die Box im Netz hat oder nicht) erfolgen und falls es in Zukunft noch mehr geben sollte als die RTC kann der Kommandozeilenparameter ebenfalls genutzt werden.
Das restliche RTC-Handling (setzen der Systemzeit beim Hochfahren und das Speichern vor dem Runterfahren) erfolgte bisher ja auch ausserhalb des sectionsd also ganz nach dem Motto:
Melde mich wieder wenns was neues gibt!"one tool for one job"
heisly
-
- Interessierter
- Beiträge: 46
- Registriert: Sonntag 22. August 2004, 16:31
Also, wie versprochen, hier nochmal eine neue Version des modifizierten sectionsd.
Falls die Systemzeit beim Start des sectionsd bereits gesetzt wurde (z.B. per RTC Modul ), einfach den sectionsd mit dem Kommandozeilenparameter "-tc" starten. Dann rennt der timerd sofort los. Die sonst übliche Zeitsysnchronisation via DVB oder NTP bleibt dabei unberührt erhalten:
Hier Auszüge aus dem Bootlog:
Da der RTL Transponder kein (korrektes) Zeitsignal sendet, schlagen die folgenden Synchronisierungsversuche via DVB zunächst fehl:
Ein Zapping auf z.B. SAT 1 liefert etwas später dann die DVB-Zeit:
Ich würde mich freuen, wenn es noch jemand testen könnte (http://morlaundmorpheus.de/tuxbox/sectionsd.tar.gz) oder seine Meinung dazu hier kundtut.
heisly
Falls die Systemzeit beim Start des sectionsd bereits gesetzt wurde (z.B. per RTC Modul ), einfach den sectionsd mit dem Kommandozeilenparameter "-tc" starten. Dann rennt der timerd sofort los. Die sonst übliche Zeitsysnchronisation via DVB oder NTP bleibt dabei unberührt erhalten:
Hier Auszüge aus dem Bootlog:
Code: Alles auswählen
[sectionsd] Started with correct system time
[sectionsd] Caching max 6000 events
[sectionsd] Caching 14 days
[sectionsd] Events are old 60min after their end time
[timeThread] Time is already set by system, trying to sync it via DVB
Code: Alles auswählen
[sectionsd] getUTC: read: Connection timed out
[sectionsd] getUTC: read: Connection timed out
Code: Alles auswählen
[timeThread] - 12.11.2006 19:31:19, tim: Sun Nov 12 19:31:19 2006
[timeThread] Time set via DVB, going to sleep for 60 seconds.
heisly
-
- Tuxboxer
- Beiträge: 2331
- Registriert: Donnerstag 24. März 2005, 21:52
noch nen komandozeilenparameter ??
kann man das nicht automatisieren ??
ich weiss nicht, was passiert, wenn man den ds1307 treiber ordentlich geladen hat. kann die sectionsd nicht abhecken, ob eine datei (/dev/dbox/clock) durch den treiberload besteht. wenn nicht bleibt alles wie gehabt.
man muss doch den armen sectionsd nicht unnötig belasten.
oder seh ich da was falsch ??
pseudocode an
if vorhanden ? /dev/dbox/clock,dann
ist schon die aktuelle zeit da vom rtc modul
ansonsten
alles wie gehabt
pseudocode aus
kann man das nicht automatisieren ??
ich weiss nicht, was passiert, wenn man den ds1307 treiber ordentlich geladen hat. kann die sectionsd nicht abhecken, ob eine datei (/dev/dbox/clock) durch den treiberload besteht. wenn nicht bleibt alles wie gehabt.
man muss doch den armen sectionsd nicht unnötig belasten.
oder seh ich da was falsch ??
pseudocode an
if vorhanden ? /dev/dbox/clock,dann
ist schon die aktuelle zeit da vom rtc modul
ansonsten
alles wie gehabt
pseudocode aus
-
- Developer
- Beiträge: 457
- Registriert: Sonntag 23. März 2003, 00:39
warum steht doch in den Beiträgen oben...mb405 hat geschrieben:noch nen komandozeilenparameter ??
Der sectionsd muss doch nur wissen, dass die Uhrzeit "gut" ist und dies dem timerd mitteilen. Ob das nun durch rtc oder eine funkuhr oder ... passiert ist, hat ihn nicht zu interessieren; der Aufrufer des sectionsd ist dafür verantwortlich, bei Bedarf den Kommandozeilenparameter hinzuzufügen oder wegzulassen.
Belastet wird der sectionsd dadurch überhaupt nicht bzw. auf jeden Fall weniger als bei jeder anderen Lösung (z.B. nach /dev/tuxbox/clock oder sowas zu schauen, obwohl das ja auch "nix" kostet). Mit der einen Änderung ist das jetzt für den sectionsd gegessen, egal welche Möglichkeiten zur initialen Zeitsetzung in Zukunft dazukommen sollten.
ciao,
ChakaZulu
-
- Tuxboxer
- Beiträge: 2331
- Registriert: Donnerstag 24. März 2005, 21:52
@ChakaZulu
ist schon richtig, was du schreibst, und leuchtet mir auch ein
ich dachte nur, das es eleganter wäre, einzelne optionen abzufragen, und bei nichtvorhandensein, dann eine andere zu benutzen.
rtc->ntp->epg
das wäre doch als abfragereihenfolge ideal.
wenn eins nicht ist, dann nimmt er das nächste, bis er es hat.
kannst du mir bei der gelegenheit mal erklären, was die zeilen zu bedeuten haben, damit ich das besser verstehe ??
====================================================
time_t actTime;
actTime=time(NULL);
first_time = false;
pthread_mutex_lock(&timeIsSetMutex);
timeset = true;
time_ntp = true;
pthread_cond_broadcast(&timeIsSetCond);
pthread_mutex_unlock(&timeIsSetMutex );
eventServer->sendEvent(CSectionsdClient::EVT_TIMESET, CEventServer::INITID_SECTIONSD, &actTime, sizeof(actTime) );
====================================================
ist schon richtig, was du schreibst, und leuchtet mir auch ein
ich dachte nur, das es eleganter wäre, einzelne optionen abzufragen, und bei nichtvorhandensein, dann eine andere zu benutzen.
rtc->ntp->epg
das wäre doch als abfragereihenfolge ideal.
wenn eins nicht ist, dann nimmt er das nächste, bis er es hat.
kannst du mir bei der gelegenheit mal erklären, was die zeilen zu bedeuten haben, damit ich das besser verstehe ??
====================================================
time_t actTime;
actTime=time(NULL);
first_time = false;
pthread_mutex_lock(&timeIsSetMutex);
timeset = true;
time_ntp = true;
pthread_cond_broadcast(&timeIsSetCond);
pthread_mutex_unlock(&timeIsSetMutex );
eventServer->sendEvent(CSectionsdClient::EVT_TIMESET, CEventServer::INITID_SECTIONSD, &actTime, sizeof(actTime) );
====================================================
-
- Developer
- Beiträge: 2183
- Registriert: Mittwoch 10. Dezember 2003, 07:59
time_t actTime;
actTime=time(NULL); -> actTime auf aktuelle Zeit setzen
first_time = false;
pthread_mutex_lock(&timeIsSetMutex); -> sich die timeIsSetMutex holen um timeIsSetCond vor parallelem Zugriff zu schützen
timeset = true;
time_ntp = true;
pthread_cond_broadcast(&timeIsSetCond); -> den anderen Threads Bescheid sagen dass die Zeit gesetzt ist
pthread_mutex_unlock(&timeIsSetMutex ); -> mutex wieder freigeben
eventServer->sendEvent(CSectionsdClient::EVT_TIMESET, CEventServer::INITID_SECTIONSD, &actTime, sizeof(actTime) ); -> Neutrino Bescheid sagen dass Zeit gesetzt ist
... oder so ähnlich
actTime=time(NULL); -> actTime auf aktuelle Zeit setzen
first_time = false;
pthread_mutex_lock(&timeIsSetMutex); -> sich die timeIsSetMutex holen um timeIsSetCond vor parallelem Zugriff zu schützen
timeset = true;
time_ntp = true;
pthread_cond_broadcast(&timeIsSetCond); -> den anderen Threads Bescheid sagen dass die Zeit gesetzt ist
pthread_mutex_unlock(&timeIsSetMutex ); -> mutex wieder freigeben
eventServer->sendEvent(CSectionsdClient::EVT_TIMESET, CEventServer::INITID_SECTIONSD, &actTime, sizeof(actTime) ); -> Neutrino Bescheid sagen dass Zeit gesetzt ist
... oder so ähnlich
-
- Interessierter
- Beiträge: 46
- Registriert: Sonntag 22. August 2004, 16:31
mb405 hat folgendes geschrieben:
Ich finde es geschickter nur beim Start auf die RTC-Zeit zurückzugreifen, damit Timer sofort aktiv sind, später soll dann die Uhr mit einer zuverlässigen Quelle synchronisiert werden. Das erspart dann das Handling zum Stellen der in der RTC hinterlegten Uhrzeit.
Und wenn der NTP-Server mal nicht erreichbar ist, oder lediglich eine Timeraufnahme auf einem "zeitlosen" Transponder durchgeführt wird, läuft die RTC auch nicht so schnell davon, wenn die Uhrzeit nicht jedes Mal synchronisiert wird.
Gruß, heisly
Das Problem hierbei ist, dass man unterscheiden muss, ob der sectionsd die Zeit zum ersten mal holt oder sich bereits im zyklischen Zeitabgleich befindet. Denn ständig die Uhrzeit aus der RTC auszulesen macht ja keinen Sinn.rtc->ntp->epg
...
wenn eins nicht ist, dann nimmt er das nächste, bis er es hat.
Ich finde es geschickter nur beim Start auf die RTC-Zeit zurückzugreifen, damit Timer sofort aktiv sind, später soll dann die Uhr mit einer zuverlässigen Quelle synchronisiert werden. Das erspart dann das Handling zum Stellen der in der RTC hinterlegten Uhrzeit.
Und wenn der NTP-Server mal nicht erreichbar ist, oder lediglich eine Timeraufnahme auf einem "zeitlosen" Transponder durchgeführt wird, läuft die RTC auch nicht so schnell davon, wenn die Uhrzeit nicht jedes Mal synchronisiert wird.
Gruß, heisly
-
- Developer
- Beiträge: 2183
- Registriert: Mittwoch 10. Dezember 2003, 07:59
ich würde es so machen:
"keine weitere Synchronisation von einer "zuverlässigen" Quelle"
"keine weitere Synchronisation von einer "zuverlässigen" Quelle"
Code: Alles auswählen
cvs: WARNING: Read-only repository access mode selected via `cvs -R'.
Using this option to access a repository which some users write to may
cause intermittent sandbox corruption.
Index: sectionsd.cpp
===================================================================
RCS file: /cvs/tuxbox/apps/tuxbox/neutrino/daemons/sectionsd/sectionsd.cpp,v
retrieving revision 1.230
diff -u -r1.230 sectionsd.cpp
--- a/sectionsd.cpp 14 Nov 2006 20:36:30 -0000 1.230
+++ b/sectionsd.cpp 16 Nov 2006 21:40:49 -0000
@@ -256,6 +256,7 @@
}
bool timeset = false;
+bool bTimeCorrect = false;
pthread_cond_t timeIsSetCond = PTHREAD_COND_INITIALIZER;
pthread_mutex_t timeIsSetMutex = PTHREAD_MUTEX_INITIALIZER;
@@ -5563,8 +5564,21 @@
while(1)
{
+ if (bTimeCorrect == true){ // sectionsd started with parameter "-tc"
+ if (first_time == true) { // only do this once!
+ time_t actTime;
+ actTime=time(NULL);
+ pthread_mutex_lock(&timeIsSetMutex);
+ timeset = true;
+ pthread_cond_broadcast(&timeIsSetCond);
+ pthread_mutex_unlock(&timeIsSetMutex );
+ eventServer->sendEvent(CSectionsdClient::EVT_TIMESET, CEventServer::INITID_SECTIONSD, &actTime, sizeof(actTime) );
+ printf("[timeThread] Time is already set by system, no further timeThread work!\n");
+ break;
+ }
+ }
- if ( ntpenable && system( ntp_system_cmd.c_str() ) == 0)
+ else if ( ntpenable && system( ntp_system_cmd.c_str() ) == 0)
{
time_t actTime;
actTime=time(NULL);
@@ -5575,8 +5589,7 @@
pthread_cond_broadcast(&timeIsSetCond);
pthread_mutex_unlock(&timeIsSetMutex );
eventServer->sendEvent(CSectionsdClient::EVT_TIMESET, CEventServer::INITID_SECTIONSD, &actTime, sizeof(actTime) );
-
- }else{
+ } else {
if (scanning && (getUTC(&UTC, true))) // always use TDT, a lot of transponders don't provide a TOT
{
tim = changeUTCtoCtime((const unsigned char *) &UTC);
@@ -6634,7 +6647,7 @@
SIlanguage::loadLanguages();
try {
- if (argc < 1 || argc > 3) {
+ if (argc < 1 || argc > 4) {
printHelp();
return EXIT_FAILURE;
}
@@ -6649,6 +6662,10 @@
update_eit = false;
printf("[sectionsd] EIT update disabled\n");
}
+ else if (!strcmp(argv[i], "-tc")) {
+ bTimeCorrect = true;
+ printf("[sectionsd] Started with correct system time\n");
+ }
else {
printHelp();
return EXIT_FAILURE;
-
- Tuxboxer
- Beiträge: 2331
- Registriert: Donnerstag 24. März 2005, 21:52
-
- Tuxboxer
- Beiträge: 2331
- Registriert: Donnerstag 24. März 2005, 21:52
-
- Interessierter
- Beiträge: 46
- Registriert: Sonntag 22. August 2004, 16:31
In Houdinis Beispiel wars das dann:
Dann muss man die RTC allerdings selbst stellen (zumindest einmalig oder wenn sie abweicht). Also zunächst ein "date ..." danach ein "hwrtc systohw".
Ich wäre damit eigentlich nicht so glücklich, da ein komfortables Handling über Neutrino (noch) fehlt. Außerdem empfände ich es eher als Rückschritt, wenn man in Zukunft die Zeit "von Hand" stellen müsste.
Code: Alles auswählen
[timeThread] Time is already set by system, no further timeThread work!
Ich wäre damit eigentlich nicht so glücklich, da ein komfortables Handling über Neutrino (noch) fehlt. Außerdem empfände ich es eher als Rückschritt, wenn man in Zukunft die Zeit "von Hand" stellen müsste.
-
- Developer
- Beiträge: 457
- Registriert: Sonntag 23. März 2003, 00:39
hi,
die weitere Synchronisation würde ich auch nicht abschalten, warum sollte man das denn machen? Die RTC soll ja nur die Zeit überbrücken, während der die Box aus ist. Wenn man die korrekte Systemzeit nur einmal und dann nie wieder setzt, dann ist die Zeit recht schnell wieder falsch, trotz RTC. Im halt-Script wird/soll die Systemzeit ja auch wieder in die RTC geschrieben werden.
ciao,
ChakaZulu
die weitere Synchronisation würde ich auch nicht abschalten, warum sollte man das denn machen? Die RTC soll ja nur die Zeit überbrücken, während der die Box aus ist. Wenn man die korrekte Systemzeit nur einmal und dann nie wieder setzt, dann ist die Zeit recht schnell wieder falsch, trotz RTC. Im halt-Script wird/soll die Systemzeit ja auch wieder in die RTC geschrieben werden.
ciao,
ChakaZulu
-
- Tuxboxer
- Beiträge: 2331
- Registriert: Donnerstag 24. März 2005, 21:52
ja genau.
einfach am systemstart die zeit vom rtc holen.
dann weiter periodisch per ntp/dvb holen, und eine abfrage rein, nur stellen, wenn mehr als 1minute abweichung ist(das wäre das nonplusultra). ansonsten stellt sich ja die boxzeit bei manchen sendern auf utopische werte.
die rtc zeit als quasi referenz nehmen.
einfach am systemstart die zeit vom rtc holen.
dann weiter periodisch per ntp/dvb holen, und eine abfrage rein, nur stellen, wenn mehr als 1minute abweichung ist(das wäre das nonplusultra). ansonsten stellt sich ja die boxzeit bei manchen sendern auf utopische werte.
die rtc zeit als quasi referenz nehmen.
-
- Interessierter
- Beiträge: 46
- Registriert: Sonntag 22. August 2004, 16:31
mb405 hat geschrieben:
Ich bin mit meiner zweiten Lösung zufrieden und habe es so momentan (seit dem 12.11.) im JTG eingebaut. Hat denn sonst noch jemand eine RTC eingebaut? Und möchte evtl. testen?
Falls Bedarf besteht, kann ich hier gerne noch Hilfestellung geben, was das Einbinden des modifizierten sectionsd in ein aktuelles JTG-Image angeht.
Grüße, heisly
Aber gerade dann könnte die Zeit utopische Werte annehmen! Man müsste eher sagen, dass die Zeit max. z.B 10 Min. daneben liegen darf. Ist es im Rahmen, wird die rtc-Zeit aktualisiert. Aber was macht man, wenn die rtc TATSÄCHLICH mal davon gelaufen ist? Dann hätte man ewig ne falsche Zeit, bis man das von Hand korrigiert. Und es könnte auch Probleme bei der Zeitumstellung machen, wobei ich mir nicht sicher bin, wie das in Linux zeittechnisch verarbeitet wird.nur stellen, wenn mehr als 1minute abweichung ist(das wäre das nonplusultra). ansonsten stellt sich ja die boxzeit bei manchen sendern auf utopische werte
Ich bin mit meiner zweiten Lösung zufrieden und habe es so momentan (seit dem 12.11.) im JTG eingebaut. Hat denn sonst noch jemand eine RTC eingebaut? Und möchte evtl. testen?
Falls Bedarf besteht, kann ich hier gerne noch Hilfestellung geben, was das Einbinden des modifizierten sectionsd in ein aktuelles JTG-Image angeht.
Grüße, heisly
-
- Tuxboxer
- Beiträge: 2331
- Registriert: Donnerstag 24. März 2005, 21:52
-
- Neugieriger
- Beiträge: 5
- Registriert: Freitag 9. März 2007, 14:23
-
- Tuxboxer
- Beiträge: 2614
- Registriert: Montag 20. Mai 2002, 10:49
- Image: JTG-Image [IDE] Version 2.4.4
- Image: (7025SS) Merlin
-
- Erleuchteter
- Beiträge: 710
- Registriert: Dienstag 3. September 2002, 12:54
-
- Tuxboxer
- Beiträge: 5873
- Registriert: Samstag 23. Februar 2002, 22:46
-
- Tuxboxer
- Beiträge: 6119
- Registriert: Mittwoch 3. April 2002, 00:32
-
- Erleuchteter
- Beiträge: 710
- Registriert: Dienstag 3. September 2002, 12:54
bevor missverständnisse auftretenGorcon hat geschrieben:Edit: Habe gerade gesehen das Du die Beschreibung im Wiki nachgetragen hast, so ist es dann wenigstens alles beisammen.
- die bildbeschreibung stammt nicht von mir - (c) ist mir unbekannt
- das editieren im wiki hat "MTM" gemacht - nicht ich
- ob das anzapfen des I²C an dieser stelle zuverlässig klappt wurde von mir NICHT erprobt.
ob das also so clever ist das ungeprobt ins wiki zu stellen?!
bei meinen tests wurde stets reproduzierbar das FE/Tuner ausser gefecht gesetzt und somit kein empfang mehr bei angeschlossener RTC. ob da ein schaltungsfehler, systematischer fehler etc. meinerseits vorlag kann ich nicht beantworten.
wenn ich mich recht erinnere gab es auch eine entsprechende fehler-meldung im log.
@gorcon: bitte teste diesbzgl. nochmal.
@SoLaLa: mhh, könnte natürlich auch sein...
-
- Tuxboxer
- Beiträge: 5873
- Registriert: Samstag 23. Februar 2002, 22:46