ntpd für OE2.0

Hi,

nachdem die letzten Tage mal wieder hier und da ein paar Uhren flasch gingen, wurde mir wieder bewusst, dass ich die Situation mit Transpondertime schon lange nervig finde. Als leicht von korrekter Zeit besessener NTP-Fan ist mir auch nichts von dem genug, was bereits zirkuliert - ntpdate nur beim Booten oder bestenfalls über Cron halte ich für einen billigen Hack, wenn man doch den wahren Pille haben könnte - ntpd für die Dreambox wurde ja schon hier und da gesichtet. Beim letzten Versuch (Jahre her) fand ich dann aber nur Builds, die ntpd als glorifiziertes ntpdate benutzten - und auf der dm800 führte der Versuch eines echten ntpd-Betriebs in wenigen Minuten in die ferne Zukunft, so dass ich das Experiment erstmal gelassen habe.

Hier ist ein neuer Versuch: Aktuelles ISC NTP für OE2.0 mips32el, bisher ausschließlich getestet auf der 7020HD und dort auf den ersten Blick funktionabel. Es handelt sich um das Paket aus OpenEmbedded Core mit diversen Anpassungen für die Dreambox. Anbei drei Pakete:

• ntp enthält den Daemon, ein ntp.conf und den Startscript, der nach rcS.d geht, damit die Zeit vor dem Start von enigma2 steht.
• ntp-tickadj habe ich optional gemacht (Recommends statt Depends), wer damit experimentieren will (oder muss) kann es installieren, aber für den Anfang sollte das nicht nötig sein.
• ntp-bin sind die optionalen Utilities, die man zum Betrieb nicht dringend braucht, aber für den Timekeeping-Fan ist sowas wie ntpq -p natürlich unverzichtbar, um der Funktion der Software nachzugehen. Zum Testen unbedingt installieren, sonst ist man ja blind.

Um die Installation von ntp wirklich abzuschließen, muss man E2 noch abgewöhnen, die Transpondertime zu syncen: Erst E2 anhalten

init 4

und ein paar Sekunden warten, bis es wirklich weg ist (enigma2 aus der Ausgabe von ps ax verschwunden). Dann /etc/enigma2/settings editieren und um die Zeile

config.misc.useTransponderTime=false

ergänzen (ACHTUNG, wenn man von ntp genug hat, dran denken das wieder zu entfernen). Dann zur Krönung die Maschine mit reboot durchstarten und sobald sie wieder erreichbar ist, mit ntpq -p mal gucken, ob sie wirklich tut was man erwartet. Dann bitte /etc/ntp.conf anpassen, wenn man bessere NTP-Server verfügbar hat als die aus dem Pool (etwa welche vom ISP, oder die eigene DCF77- oder GPS-Uhr).

A short blurb in something resembling the english language:

Lately some stations have managed to broadcast completely wrong time bases on their DVB transponders and this didn't happen for the first time, nor will it be the last. I consider full NTP daemon operation as the one true solution, but so far this either was solved incompletely (ntpd as a glorified one-shot replacement for ntpdate) or cheaply (one-shot or at best cron triggered ntpdate). Real ntpd also failed on my previous box (DM800HD PVR) by letting the clock speed to 2016 within a couple of minutes, so there's something wrong with the 2.6.18 kernel on that platform. Anyway, with Kernel 3.2 on a 7020HD, it seemed a new test for ntpd fitness was in order.

So please find attached mips32el packages of ISC ntp (the daemon, ntp.conf and init script), ntp-bin (tools like ntpq needed to monitor ntpd's proper operation) and ntp-tickadj (necessary only in special cases) in a build inspired by the OE core one, but stripped off unnecessary stuff (like 99% of refclocks) and tuned for the Dreambox. After installing ntp, make sure to fix your /etc/ntp.conf, disable useTransponderTime in the E2 settings file (edit only after stopping E2!) and reboot to test the init script. You may also use /etc/init.d/ntp start to test it without reboot first, or if you ran into problems. To monitor the daemon, use ntpq -p on the box.

So, without much further ado, Happy Testing!

Thanks & HTH,
Andre.

Zitat

Originally posted by Gunah
dank dir, wärst du ggf. so nett und stellst uns das Rezept zur Verfügung

Uh. Das ist doch noch so quick&dirty^Wwork in progress, war mein erster Versuch und basiert primär auf halbwissendem Rumfuhrwerken in dem Rezept aus OE Core. Und Feedback gab's auch noch keins
Aber sei's drum, ich häng's mal an - nehme auch gern Verbesserungsvorschläge zur Kenntnis (und bei Gefallen auch auf). Das Rezept steckt bei mir in einem privaten Overlay mit Prio 100, weil die Namen sich von OE Core ja nicht unterscheiden.

HTH,
Andre.

PS: Wenn das größere Kreise zieht als unser kleiner Proof of Concept hier und von einem Image-Team vielleicht gar als Default ausgeliefert würde, müsste man sich mal Gedanken um die Nutzung von pool.ntp.org machen. Wir sind zwar kein "Vendor" im Sinne der Definition durch den Pool (da wäre vielleicht DMM gefragt) - aber wir könnten trotzdem unabsichtlich für eine Menge zusätzliche Last sorgen. Wenn es ernst wird müsste man dann doch eine Vendor-Zone beantragen, als Gegenleistung wäre der Pool sicher an ein paar der ohnehin von Image-Teams betriebenen Server als weitere Pool-Member interessiert (zumindest so weit es physische Maschinen sind). Ich hab wenigstens schon mal den Join The Pool-Aufruf mit ins ntp.conf aufgenommen, aber wie gesagt - das Thema ist etwas sensibel.

Re,

Testen wurde hier spannender als erwartet. Am Montag stand die Kiste, die 17:00 von EPGrefresh geweckt werden sollte, gleich mal im *serial setup* - das hatte ich vorher noch nie. Würde ich unter reine Koinzidenz abbuchen, mit Telnet drauf und im BIOS ein Save&Reboot reichte, danach war sie wieder wie immer - und bootet seitdem auch wieder ohne Nachhilfe.

Was dann blieb, war die verwirrende Beobachtung, dass die Uhr manchmal unnatürlich driftet. Gleich am zweiten Tag fand ich sie mit -498ppm vor. Erster Verdacht war deutliche Temperaturunterschiede: Wenn sie tief in der Nacht in den Standby geht und beim Runterfahren die Drift saved, dann bei offenem Fenster auskühlt und 17:00 wieder startet und die Drift aus wärmeren Zeiten benutzt, dann ist das sicher nicht glücklich. Aber die Abweichungen waren mir dafür zu groß und vor allem zu erratisch und gleichzeitig seltsam systematisch. Längeres genaues Hingucken ließ dann immer mehr den Verdacht aufkommen, dass irgendwas anderes an der Uhr rumfummelt - und es ist nicht Transpondertime (passiert nicht, wenn ich meine kompletten Favourites durchzappe). Es kristallisierte sich auch heraus, dass es nur passiert, wenn die Box im Idle ist, nicht aber wenn sie aktiv läuft. Konkret hat bei mir besagtes Irgendwas die Uhr immer wieder mal um 2s in die Zukunft geschickt - exakt 2s wohlgemerkt. Ich habe es sogar einmal zufällig genau zwischen zwei Testsyncs mit ntpd -dgq ertappt, und es war schon verdächtig, dass der Zeitpunkt ziemlich exakt ein Vielfaches von 30min nach dem Bootzeitpunkt lag. Alles sehr mysteriös.

Mir schwante langsam, dass da vielleicht ein RTC-Sync dahintersteckt, aber ich hätte den in den proprietären Kernel-Treibern von DMM vermutet und daher nicht erwartet, den so leicht zu finden. Zum Glück war es letztlich einfacher, weil er im E2 steckt. Und das isser:

[eDVBLocalTimeHandler] no transponder tuned... or no TDT/TOT avail .. try to use RTC :)
[eDVBLocalTimeHandler] RTC time is 'Thu Sep 19 19:25:27 2013'
[eDVBLocalTimeHandler] Receiver time is 'Thu Sep 19 19:25:25 2013'
[eDVBLocalTimeHandler] RTC to Receiver time difference is -2 seconds
[eDVBLocalTimeHandler] set Linux Time to RTC Time

Wuargh!

Kriegt man das irgendwie abgeschaltet? Kommt das doch im Ernst jede halbe Stunde vorbei und haut dem ntpd, der sich gerade auf <400µs Abweichung an UTC rangesaugt hat, einen 100kg Westminster-Gong übern Kopp! Der ntpd zuckt dann spastisch die nächsten 20min, das irgendwie zu verdauen, und dann kommt der nächste Schlag. Der Mechanismus scheint ein Relikt von Transpondertime zu sein (speziell, dass er nicht triggert, wenn man einen Sender getuned hat, lässt da kaum Zweifel). Sollte eigentlich zusammen mit Transpondertime abschaltbar sein. Eigentlich sollte eher die RTC vom Kernel nachgeführt werden, wenn die Kernel PLL dank NTP in sync ist. Ich fürchte aber mal, dass eDVBLocalTimeHandler die RTC nur genau dann explizit synced, wenn Transpondertime benutzt wird, um die Uhr zu stellen. Das ist der Worst Case: Nach dem Abschalten von TT dürfte die RTC immer weiter von der realen Zeit wegdriften, und während der ntpd einen 2s-Schlag aller halbe Stunde noch ausregeln kann, wird das nicht lange gut gehen. Und das Gewackel der Uhr ist ohnehin potthässlich, auch wenn es nur 1s wäre...

Bleibt interessant. Für den dauerhaften Einsatz im Normalbetrieb ist es so jedenfalls noch nicht reif.

HTH & Thanks,
Andre.

Zitat

Originally posted by Gunah
mir ist auch gerade aufgefallen, dass durch die Uhrumstellung des Transponders scheinbar die EPG Daten durcheinander gewurfen werden und dadurch teils gelöscht werden -.-

Die Monduhr bei der ARD (oder war's doch die vom ZDF?) hat ab dem 2.10. im EPGRefresh-Thread für viel Spaß gesorgt - geht hier los. Ich selbst habe direkt überhaupt nichts davon mitbekommen, da hier immer noch ntpd im Test und TransponderTime aus ist - war sehr praktisch, um das Problem zu isolieren. Bewährt hat sich NTP damit auf jeden Fall, leider steht oben aufgezeigtes Problem mit eDVBLocalTimeHandler im Raum. Ich hab zwar experimentell im Startscript was drin das versucht die RTC wenigstens auf 1s an die NTP-Zeit ranzuholen, aber das ist nicht massentauglich und es ist auch nicht exakt genug. Man kann die RTC scheinbar auch nur setzen, aber nicht restarten (den Startzeitpunkt einer integralen Sekunde verschieben) - wird also immer mit einem Fehler von +/- 0.5s behaftet bleiben. Ich liege mit der UTC-synchronen Uhr z.B. gerade 0.2s vor der RTC und es macht in beiligendem Script auch keinen Unterschied, ob ich das "Tune Me"-sleep auf 0.25s oder 0.75s stelle - wenn ich nicht gerade die integrale Grenze überschreite. Nervt mich etwas. Sicher, angesichts von Timewarps um 81s bei Transpondertime am Wochenende ist das Jammern auf hohem Niveau, aber wenn schon NTP, dann richtig

HTH,
Andre.

Zitat

Originally posted by mani0007
Ich hätt ene frage zu den ntpd Daemon ist der mir rawdcf compiliert???

Nö. Ich habe keinen großen Sinn darin gesehen, auf der Dream eine Refclock zu betreiben[1], Ziel war eher ein wirklich guter NTP-Sync gegen Server im Heimnetz oder Internet. Der Build erfolgte im Interesse eines kompakten Executables daher mit (die local clock ist da schon ein Zugeständnis an die Tradition, eigentlich bringt die nix):

--enable-all-clocks=no --enable-parse-clocks=no --enable-LOCAL-CLOCK

Zitat

Würde gerne meine Expert mouse clock 2 USB am Receiver betreiben.

Das ist ein RAWDCF parse driver, also in diesem Paket hier nicht drin. Das BB-Rezept hängt aber an

Zitat

Bloß der Versuch scheitert kläglich wenn ich den ntpd Daemon installiere und dann die VU+ neustarte startet sie nicht mehr. Ich muss dann das Image komplett neu aufspielen damit es wieder läuft.

Das Paket ist im DMM OE2.0 gebaut, keine Ahnung was das auf einer VU+ anrichtet, ich kenne da weder das Build Environment noch die letztlich auf der Box landenden Strukturen. Ich hänge mich z.Z. in rcS.d als S42ntpd ein (das ist nach meinem letzten Kenntnisstand etwas straffer als nötig, frühes rc3.d würde auch langen, schaden sollte es aber auch nicht). Das Script könnte den Bootvorgang lange verzögern, falls keiner der Server im ntp.conf erreichbar ist, aber eigentlich sollte es nicht freezen. Um das zu testen, könntest Du direkt nach der Installation des Pakets den S42ntpd in rcS.d entschärfen, so dass es erstmal nicht beim Booten gestartet würde (z.B. umbenennen in _S42ntpd). Dann kann man interaktiv gucken, was das Teil treibt. Ist aber wie gesagt müßig, wenn es um refclocks geht - die sind alle amputiert.

[1] Argumente: Keine seriellen Schnittstellen, die meisten Refclock-Treiber sind eh nicht an einer STB zu betreiben, die ntpd Exe ist schon ohne Refclocks 371KiB und damit verflucht fett, langsame CPU mit anderen Aufgaben, keine Ahnung wie sehr diverse Modelle driften, die STB ist nicht 24/7 an also taugt sie eh nicht als Refclock, E2 dreht gern selbst mal an der Uhr, etc.

HTH anyway,
Andre.

Zitat von xtreams

hier einmal ein push für die die auch am durchdrehen sind wenn die box mal wieder auf 1970 springt

das plugin funzt immernoch einwandfrei und ich möchte danke sagen

Das hört man gern.

Auch bei mir werkelt immer noch die 7020HD (toi toi toi) und unverändert mit diesem ntpd-Paket (OMG das ist fast 10 Jahre her). Neben der driftenden RTC hatte ich noch einen größeren Glitch, als mal dank Stromausfall (hier ist so'n metallisierter Folien-Ballon in ein Umspannwerk gesegelt und der Dominoeffekt hat die Stadt samt Umland dunkel geschaltet, war überregional in den News) zwar die Dreambox normal wieder anlief, aber der Switch an dem sie hängt intransparent geworden war. Seitdem weiß ich, dass der initiale Sync bei 0 erreichbaren NTP-Servern nie endet - die Kiste steht dann einfach mit dem Balken bei 20% oder so rum und macht nix mehr. Bissel doof.

Andererseits funktioniert es gut genug, dass ich mich nicht aufraffen kann, ernsthaft was dran zu ändern...

Gruß & Dank,

Andre.