[Patch] sectionsd - statt rdate auch ntpclient bzw. ntpdate

[JimPoison]

kann mir jemand sagen, welche abhängigkeiten das ntpd-binary hat (also welche dateien in einem image außer dem reinen binary für das funktionieren des openntpd vorhanden sein müssen und an welchem ort)?
alternativ hätte ich natürlich auch nix dagegen, wenn jemand ein statisches binary zur verfügung stellen würde (z.b. zum nachrüsten in ein altes image)

[seife]

Desweiteren habe ich immer noch nicht rausbekommen wann die Uhr mal richtig, ausser beim
Neustart, gestellt wird. Vielleicht funktioniert das beim Kernel 2.4 nicht korrekt, bzw. vll muss
da noch etwas spezielles im Kernel aktiviert werden.
Bringt ja nichts wenn die Uhr erst nach 4 Tagen mit 3 Minuten Ungenauigkeit mal gestellt wird.

Ich habe so das Gefühl, dass die Ungenauigkeit der dbox-Uhr etwas zuviel für den adjtime(3) syscall ist.

Dieser Patch könnte da helfen: linux-2.4.37-allow-bigger-adjtime-adjustments.diff
Er erlaubt, dass adjtime die Uhr um bis zu 2 % schneller laufen lässt anstelle der 0,5% die normal sind.

Achtung, der Kernel muss dazu neu ausgepackt werden etc, also am besten "make distclean".

Getestet habe ich es allerdings noch nicht, noch baut der Kernel

Wenn du den ntpd dann so startest:

Code: Alles auswählen

ntpd -d -f /var/etc/ntpd.conf

(evtl. vorher die Uhr vorher um eine Minute verstellen oder so...), dann solltest du sowas im Terminalfenster sehen, mit gegen 0 tendierendem Offset:

Code: Alles auswählen

reply from 192.168.200.1: offset 0.149636 delay 0.001319, next query 163s
adjusting local clock by 0.144022s
reply from 192.168.200.1: offset 0.079181 delay 0.005570, next query 92s
reply from 192.168.200.1: offset 0.042703 delay 0.001163, next query 90s
adjusting local clock by 0.042703s
reply from 192.168.200.1: offset 0.007113 delay 0.001296, next query 310s
reply from 192.168.200.1: offset 0.031771 delay 0.001160, next query 312s
reply from 192.168.200.1: offset 0.056683 delay 0.001337, next query 322s
reply from 192.168.200.1: offset 0.080007 delay 0.005815, next query 305s

Wenn er eben nicht kleiner wird, dann hilft der Patch anscheinend auch nichts...

[GetAway]

@seife

Klasse, jetzt funktioniert es zum erstenmal richtig. Den Patch hatte ich auch schon mal in den Fingern,
hatte aber die Implementierung wieder verworfen.

[seife]

Also auf meiner nokia (Kernel 2.4) geht die Uhr massiv zu langsam, da ist ohne dauerndes Nachregeln nichts drin. Bei meiner Philips (mit Kernel 2.6, bisher ohne einen solchen Patch) ist es auch so, dass openntpd (der adjtime(3) benutzt) es gerade so schafft, die Uhr korrekt zu halten, aber wenn sie z.B. 2 Min. daneben liegt, dann kriegt er das nicht mehr hin.
Da wäre xntp tatsächlich besser, weil der adjtimex(3) verwendet um die Uhr kontinuierlich und in feineren Schritten schneller oder langsamer zu machen, oder man müsste mit adjtimex(1) beim booten die Geschwindigkeit der Uhr zumindest grob nachstellen.

Ich überleg mir mal was.

Ich habe auch einen Patch in petto, der, wenn der EVT_TIMESET vom sectionsd kommt, die Uhr nicht "steppt", sondern mittels adjtime(3) nachregelt. Das ist immer besser als ein "Zeitsprung", der seltsame Folgen haben kann.

Der openntp hat übrigens jetzt auch probleme, die Uhr im Takt zu halten, vermutlich weil die jetzt zu schnell "überschwingt", ich habe aber einen Patch dafür, den ich gleich mal committen werde...
...und den Kernel-Patch habe ich auch mal committed, der tut jedenfalls, solange adjtime() nicht verwendet wird, sicher nicht weh.

[GetAway]

Der 2. Patch hat ein gutes Stück Ruhe reingebracht.