Neutrino-Images

ja aber da brauchst du nicht alles 30 min. chronyc makestep ..
sondern nur beim server wechsel bzw. bei neuer einstellung.
ich brauche das nicht .. ich habe mir ein tool geschrieben ntpstat .. das zeigt mir jetzt so was an ..

Code: Alles auswählen

key: 0160 value 0, translate: 0160 -ok-
[frontend.cpp:getEvent:908] [fe0/1] ******** FE_HAS_LOCK: freq 474000000
[fe0/1] tuning took: 181 msec (min 181 max 193)
CRemoteControl::handleMsg: EVT_TUNE_COMPLETE (59322719f001c37b)
2026-06-20 18:43:30.091 [sectionsd] commandserviceChanged: Service change to 59322719f001c37b demux #0
2026-06-20 18:43:30.092 [sectionsd] cnThread: stop eit update filter (not active)
ntp-helper.sh: Last Synchronize time with ptbtime1.ptb.de ...Sat Jun 20 18:43:25 CEST 2026
2026-06-20 18:43:30.193 [sectionsd] timeThread: Time set via NTP, going to sleep for 1800 seconds.
[zapit] parsing pmt pid 0x65 (TELE 5 HD)

da macht bei mir der helper sinn auch ohne $chronyc makestep

vanhofen hat geschrieben: ↑Sa 20. Jun 2026, 17:29 Da kommst du selbst drauf.

ja du kannst mich gut einschätzen ..
ich habe mir das noch verfeinert .. zeigt schön alles an .. auch ohne syslog

Code: Alles auswählen

2026-06-21 09:08:47.961 [sectionsd] cnThread: stop eit update filter (not active)
ntp-helper.sh: Last Synchronize time with ptbtime1.ptb.de ... 2026-06-21 09:02:48 offset: 0.000254531 seconds
2026-06-21 09:08:48.076 [sectionsd] timeThread: Time set via NTP, going to sleep for 1800 seconds.

ich mag sowas

@vanhofen .. anbei als zbv

du wirst wissen was das ist .. mach was daraus ..

Danke dir. Nettes Script. Ich glaube aber nicht, dass wir das brauchen. Der Normalo-User will einfach nur eine Uhr haben, die ungefähr genau geht. Es geht um EPG-Daten. Wenn die aktuelle Minute halbwegs gut getroffen wird, ist alles im grünen Bereich. Auf der Konsole schaut kein Standard-Benutzer nach diesen Details. Und falls doch, sind die Boardmittel, die chrony mitbringt, gut genug.

i.e.l. ist es für dich bzw. hat es mir gut dienste geleistet i.p. chrony.
ergebnis meiner beobachtung damit ist .. chrony ist stabil und mit maxpoll 10 optimal eingestellt.
schön war es auch zu beobachten wie sich chrony so langsam einpendelte ..
d.h. umso länger chrony läuft umso stabiler wir das ganze .. und ja den normalen user interessiert das nicht aber uns bzw. meiner einer schon

und deshalb bin ich manchmal so zickig .. aber wenn ich weiss .. wie wo was warum weshalb ..
dann gehts wieder und aus einem wadenbeisser wird wieder ein lämmchen ..
das hat schon den ungenannten genervt .. aber sonst wäre ich heute nicht in der lage überhaupt was zu schreiben .. als autodidakt.

@vanhofen .. anbei ein log .. vllt. kannst du das brauchen ..
ich habe im helper folgendes erfasst ..
letzte sync von chrony .. offset ist die abweichung der box zum letzten sysnc + sender
ich setze die zeit nicht neu mit $chronyc makestep .. sondern lasse chrony in ruhe weiterarbeiten.
d.h. chrony wurde nur einmal via init gestartet und werkelt mit maxroll 10 selbständig .. weiter.
und ich muss sagen das die werte für einen receiver richtig gut sind ..
also nach meinem dünken ist alles im grünen bereich ..

Ich habe gestern die Änderungen von dbt aus der Tuxbox gepickt, allerdings noch nicht bei uns gepusht. Das muss ich mir erst mal genauer anschauen. Jedenfalls wird vermutlich das helper-Script wieder wegfallen, weil die chrony-Aufrufe wieder in Neutrino hardcodet wurden. Genau das wollte ich eigentlich vermeiden, aber ich hab auch keinen Drang, unseren Code allzu weit vom Code der Anderen wegdriften zu lassen. Schön finde ich, dass chrony.conf dann nicht mehr ge-sed-et (Wort des Tages!) werden muss.

LSS: Verabschiede dich schon mal von ntp-helper-sh

ich habe das von @dbt gesehen .. also das habe ich auch im auge

das was ich wissen wollte i.p. chrony, dass habe ich gesehen und verstanden.
wichtig wäre für mich .. das man nicht starr auf pool beharrt .. also auch server berücksichtigt.
z.b. sowas

Code: Alles auswählen

conf=/etc/chrony.conf
pool=$(grep -m1 -E "^pool|^server" $conf | cut -d" " -f2)

und es war nur eine frage der zeit .. das man die einstellungen diesbezüglich für chrony anpasst.
mal sehen .. ich lass mich überraschen

leider musste ich feststellen das ntpstat noch eine fehler beinhaltete ..

auf grund der download zahlen konnte ich das nicht so stehen lassen und habe das shell script ..
so wie ich es immer mache portiert nach lua

aufruf wäre .. z.b.

Code: Alles auswählen

lua ntpstat.lua

oder ihr macht sowas .. meine empfehlung

Code: Alles auswählen

mv ntpstat.lua ntpstat
chmod +x ntpstat
\cp -f ntpstat /var/bin

ergebnis ..

Code: Alles auswählen

[jokel ~]# ntpstat --help
ntpstat (Lua-Version 2.0)

Aufruf:
  ntpstat               -> Vollständige Ausgabe
  ntpstat last          -> Zeitpunkt der letzten Synchronisation
  ntpstat next          -> Zeitpunkt der nächsten Synchronisation
  ntpstat status        -> synchronised / unsynchronised
  ntpstat tz            -> Sommerzeit/Winterzeit anzeigen
  ntpstat --help        -> Diese Hilfe
[jokel ~]#

bzw. ..

Code: Alles auswählen

[jokel ~]# ntpstat
synchronised
Last sync : 2026-06-26 09:28:29
Age       : 363s
Poll      : 10
Interval  : 1024s
LastRx    : 363s
Next sync : 2026-06-26 09:45:33
Remaining : 661s
Offset s  : 0.000028952 Sekunden.
Offset ms : 0.029 ms langsamer als NTP-Zeit.
TZ-Status : Sommerzeit (CEST)
[jokel ~]#

und somit habt ihr die zeit im blick ..

HF

[+] Spoiler

ntpstat.lua: (4.58 KiB) 31-mal heruntergeladen

@vanhofen .. info ..

Code: Alles auswählen

[jokel ~]# cat /.version
distro=NI
imagename=NI \o/ Neutrino-Image
imagedescription=Air Digital Zgemma H7 [arm-h7] Selfmade
imageversion=2026.06.30
version=9202606202606271006
describe=NI-2026.06.30-g6b564047
builddate=Sa 27. Jun 10:06:10 CEST 2026
box_model=h7
creator=NI-Buildsystem, jokel
homepage=www.neutrino-images.de
imagedir=zgemma/h7

[jokel ~]# logread |grep chrony
Jan  1 00:00:09 jokel user.info service[1234]: running /etc/init.d/chrony start 
Jan  1 00:00:09 jokel daemon.info chronyd[1270]: chronyd version 4.8 starting (+CMDMON +REFCLOCK +RTC -PRIVDROP -SCFILTER -SIGND -NTS -SECHASH +IPV6 -DEBUG)
Jan  1 00:00:09 jokel daemon.warn chronyd[1270]: Running with root privileges
Jun 27 10:30:06 jokel daemon.warn chronyd[1270]: System clock was stepped by 0.000000 seconds
Jun 27 10:30:07 jokel daemon.info chronyd[1270]: Selected source 192.53.103.108 (ptbtime1.ptb.de)
Jun 27 10:30:07 jokel daemon.warn chronyd[1270]: System clock wrong by 89.954963 seconds
Jun 27 10:31:37 jokel daemon.warn chronyd[1270]: System clock was stepped by 89.954963 seconds

[jokel ~]# chronyc tracking
Reference ID    : C035676C (ptbtime1.ptb.de)
Stratum         : 2
Ref time (UTC)  : Sat Jun 27 08:45:39 2026
System time     : 0.000388115 seconds fast of NTP time
Last offset     : +0.000177198 seconds
RMS offset      : 0.001954688 seconds
Frequency       : 2.613 ppm fast
Residual freq   : +0.083 ppm
Skew            : 5.957 ppm
Root delay      : 0.021904046 seconds
Root dispersion : 0.002532186 seconds
Update interval : 65.0 seconds
Leap status     : Normal

[jokel ~]# chronyc sources
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
^- ntp1.rrze.uni-erlangen.de     1   6   377    41   +654us[ +654us] +/-   13ms
^- ntp1.hetzner.de               2   6   377    42   -528us[ -528us] +/-   63ms
^* ptbtime1.ptb.de               1   6   377    43   +530us[ +707us] +/-   13ms

[jokel ~]# chronyc sourcestats
Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
==============================================================================
ntp1.rrze.uni-erlangen.de  17   9   848     -0.303      2.664  +1183us   795us
ntp1.hetzner.de            17   9   847     +0.607      4.465   +572us  1196us
ptbtime1.ptb.de            17   8   846     +0.083      5.531  +4081ns  1561us

[jokel ~]# ntpstat
synchronised
Last sync : 2026-06-27 10:45:39
Age       : 58s
Poll      : 6
Interval  : 64s
LastRx    : 58s
Next sync : 2026-06-27 10:46:43
Remaining : 6s
Offset s  : 0.000322359 Sekunden.
Offset ms : 0.322 ms schneller als NTP-Zeit.
TZ-Status : Sommerzeit (CEST)
[jokel ~]#

alles im grünen bereich .. wird sich noch einpegeln bis maxpoll 10 .. z.z. ist ja erst poll 6 ..

Wenn der chrony (oder ntpd) als daemon läuft, dann darf (ok, "sollte") nicht regelmäßig die Zeit manuell gesetzt werden.
Der chrony (oder ntpd) hält die Zeit konstant korrekt (und "lernt" wie falsch die interne Uhr geht und korrigiert das).

Zumindest früher hat Neutrino, wenn die Zeit via DVB aktualisiert wurde, diese Zeitkorrektur auch von den laufenden Timern abgezogen oder hinzuaddiert, damit z.b. OSD timeouts nicht kaputt gehen etc. Kann aber sein daß das heute mit monotonic_time gemacht wird und somit nicht mehr notwendig ist.

Aus meiner Sicht (aber ohne den aktuellen code gelesen zu haben...

) sollte entweder chrony einfach als daemon laufen und dann vom Neutrino gar nichts gemacht werden, oder, bei "Synchronisation via DVB" oder wenn man, warum auch immer, per "alle 30 minuten von Hand die Uhr stellen" synchronisieren will, der chrony gestoppt werden.

Das NTPdate feature im Neutrino wurde vor 1000 jahren eingeführt, damit man eben keinen ntp daemon braucht (wahrscheinlich weil es den damals nicht in der busybox gab) und weil wohl manche Transponder damals schlimm falsche Zeiten gesendet haben, so daß "Synchronisation via DVB" auch nicht für alle nutzbar war.

Einspruch, Euer Ehren.

Neutrino führt alle 30 Minuten ein "chronyc makestep" aus, was das Gleiche ist, als wenn chronyd automatisch synchronisiert, nur dass es von außen initiiert wird. Das ist für Chrony legitimes Vorgehen und macht am Zeithandling von Chrony nichts kaputt.

naja selbst die ki sagt dazu ..

Der Befehl chronyc makestep korrigiert die Systemzeit sofort und abrupt durch einen harten Zeitsprung (Step), anstatt sie langsam anzugleichen (Slew).

Hauptfunktionen und Wirkung
Sofortige Korrektur: Er zwingt den NTP-Dienst chronyd, die aktuelle Zeitabweichung (Offset) ohne Verzögerung auf null zu setzen.
Zeitersparnis: Normalerweise gleicht chrony die Zeit über Minuten oder Stunden hinweg schleichend an, um Anwendungen nicht zu stören. makestep überspringt diese Wartezeit.
Einsatzbereich: Der Befehl ist ideal nach dem Systemstart, nach dem Aufwachen aus dem Energiesparmodus oder wenn die Uhrzeit um mehrere Minuten falsch geht.

Wichtige Nebenwirkungen
Zeitsprünge: Da die Systemzeit abrupt vorwärts oder rückwärts springt, können laufende Anwendungen, Datenbank-Logfiles oder cron-Jobs kurzzeitig irritiert werden.

ergo ..
lieber die aktuelle zeitabweichung vorher prüfen ..

Bei KI-Antworten ist die Frage immer interessant. Die hast du geschickt weggelassen.

wie @seife schon schrieb ..

Code: Alles auswählen

Wenn der chrony (oder ntpd) als daemon läuft, dann darf (ok, "sollte") nicht regelmäßig die Zeit manuell gesetzt werden.
Der chrony (oder ntpd) hält die Zeit konstant korrekt (und "lernt" wie falsch die interne Uhr geht und korrigiert das).

und deshalb gibt es bei mir kein ..

Code: Alles auswählen

chronyc makestep

da mit maxpoll 10 .. also alle 17 min. chrony das selbst regelt .. da muss ich nicht alle 30 min.
dazwischenfunken.

ich wollte erst maxpoll 11 nehmen .. also alle 34 min. aber 10 reicht .. mittelding

und was sollte ich da korrigieren .. bei ..

Code: Alles auswählen

[jokel ~]# ntpstat last
2026-07-13 19:56:34 Offset 0.074 ms langsamer als NTP-Zeit.
[jokel ~]#

nichts ..

OK, gehen wir weg von "makestep". Ich habe wenig Lust, Neutrino großartig umzubauen. Was ist denn mit " chronyc burst 4/4"?

"chronyc clients" oder "chronyc tracking"

Ich tät wahrscheinlich ein skript "neutrino-timeset.sh" machen und dort drin kann man dann, ohne neutrino anzufassen, beliebige sachen machen.

Wenn der chronyd *immer* beim booten gestartet wird, dann sollte eigentlich auch die option "DVB" beim Zeiteinstellen wegfallen...

Wobei die halt auch funktioniert, wenn jemand so eine Neutrino box als "dummen" Receiver, ganz ohne Netzwerk betreibt (meine Schwiegermutter hatte das bis sie vor ein paar Jahren einen neuen Fernseher mit eingebautem SAT-Tuner bekommen hat). Und dann arbeitet der chrony auch nicht dagegen, weil er dann keinen NTP Server sieht.

So, und jetzt halte ich mich wieder raus. Nicht vergessen: ich hab gefühlt vor 10 Jahren das letzte mal in den Code geschaut, also meine Kommentare hier nicht überbewerten

seife hat geschrieben: ↑Mo 13. Jul 2026, 21:44 Ich tät wahrscheinlich ein skript "neutrino-timeset.sh" machen und dort drin kann man dann, ohne neutrino anzufassen, beliebige sachen machen.

Ich tät es "ntp-helper.sh" nennen. https://github.com/neutrino-images/ni-n ... d4dd2acd48

Hab ich dann aber paar Tage später wieder revertet, als dbt im Tuxbox-Code auch an dieser Stelle mitgemacht hat. Mich hatten die ganzen hard-codeten Sachen gestört. Da ich unseren Code aber nicht allzu weit von Tuxbox wegdriften lassen will, hab ich das wieder verworfen.

Ich muss mich korrigieren: Neutrino führt *nicht* alle 30 Minuten "chrony makestep" aus. Nur bei einem Wechsel des NTP-Servers oder wenn "chronyc tracking" einen Fehler zurückgibt, werden die Quellen neu geladen und einmalig makestep aufgerufen. Ansonsten macht Neutrino nichts und lässt chrony in Ruhe. Was dbt da umgebaut hatte, hätte ich mir auch eher mal im Detail anschauen können.

fehlt nur noch ..
https://github.com/tuxbox-neutrino/neut ... 4d6fb52b60
und deshalb musste ich das anders regeln .. nicht schön .. funzt aber

Code: Alles auswählen

2026-07-13 20:02:47.947 [sectionsd] NTP: cannot write /etc/chrony.d/neutrino-ntpserver.conf: No such file or directory

geht auch ohne

Neutrino-Images

chrony statt ntpdate

Re: chrony statt ntpdate

Re: chrony statt ntpdate

Re: chrony statt ntpdate

Re: chrony statt ntpdate

Re: chrony statt ntpdate

Re: chrony statt ntpdate

Re: chrony statt ntpdate

Re: chrony statt ntpdate

Re: chrony statt ntpdate

Re: chrony statt ntpdate

Re: chrony statt ntpdate

Re: chrony statt ntpdate

Re: chrony statt ntpdate

Re: chrony statt ntpdate

Re: chrony statt ntpdate

Re: chrony statt ntpdate

Re: chrony statt ntpdate

Re: chrony statt ntpdate

Re: chrony statt ntpdate

Re: chrony statt ntpdate