Kaputte Uhren auf den Rootserver PS?!

[dodolin]

Servus, hat hier schon jemand auf einem Rootserver PS versucht einen ntpd laufen zu lassen?

Ich musste auf meinem neuen Exemplar folgendes feststellen:
(Anmerkung: Ich habe über 24h lang gemessen, die Daten dürften also ziemlich genau sein.)

Die Systemzeit (also NICHT die CMOS / BIOS / RTC Uhr, sondern die Zeit, die der Kernel intern verwaltet) geht pro Tag über eine ganze Minute falsch! Das ist absolut inakzeptabel. Das entspricht ca. 0.8088 ms pro Sekunde. Leider kann der Kernel zumindest ohne Zusatzprogramme höchstens eine Abweichung von 0.5 ms pro Sekunde korrigieren.

Das hatte zur Folge, dass der ntpd regelmässig (wirklich regelmässig, man konnte die Uhr danach stellen :-D ) alle ca. 20 Minuten die sync verloren hat, weil die Differenz zwischen Systemzeit und dem Referenzserver zu groß wurde (obwohl er ja versucht hat, das zu beheben, aber siehe oben, mehr als 0.5 ms / s geht halt nicht...).

Das ganze sah dann so aus:

Code: Select all

[...]
Jun  3 14:57:43 trinity ntpd[3745]: time set -0.106161 s
Jun  3 14:57:43 trinity ntpd[3745]: synchronisation lost
Jun  3 15:13:56 trinity ntpd[3745]: time reset -1.587258 s
Jun  3 15:13:56 trinity ntpd[3745]: synchronisation lost
Jun  3 15:31:21 trinity ntpd[3745]: time reset -1.494811 s
Jun  3 15:31:21 trinity ntpd[3745]: synchronisation lost
Jun  3 15:53:50 trinity ntpd[3745]: time reset -1.745766 s
Jun  3 15:53:50 trinity ntpd[3745]: synchronisation lost
Jun  3 16:11:13 trinity ntpd[3745]: time reset -1.678313 s
Jun  3 16:11:13 trinity ntpd[3745]: synchronisation lost
Jun  3 16:24:22 trinity ntpd[3745]: time reset -1.099891 s
Jun  3 16:24:22 trinity ntpd[3745]: synchronisation lost
Jun  3 16:46:58 trinity ntpd[3745]: time reset -2.080249 s
Jun  3 16:46:58 trinity ntpd[3745]: synchronisation lost
Jun  3 17:07:26 trinity ntpd[3745]: time reset -1.358571 s
Jun  3 17:07:26 trinity ntpd[3745]: synchronisation lost
[...]

Ich habe extrem viel dazu gegoogelt und auch sehr viel dazugelernt. Es könnte sein, dass das nur auf dem 900 MHz Celeron auftaucht, und auf anderen CPUs nicht. Nachdem ich alles durch hatte und auch die FAQ von ntp.org inzwischen fast auswendig kenne, konnte ich dieses Problem vorerst mal beheben. Ob jetzt allerdings WIRKLICH alles so funktioniert, wie es soll, kann ich erst nach einer etwas längeren Testzeit sagen.

Genaueres werde ich wohl noch irgendwo auf meiner Webseite mal später dazu schreiben, hier nur die Kurzfassung, wie ich das Problem meine behoben zu haben (ist ein Debian System):

Code: Select all

/etc/init.d/ntp stop
apt-get install adjtimex
adjtimex --log --host ptbtime1.ptb.de
adjtimex --review
vi /etc/adjtimex.conf
ntpdate -b -s -p 4 -t 0.1 ptbtime1.ptb.de
/etc/init.d/adjtimex start
/etc/init.d/ntp start

Das dritte Kommando (adjtimex --log --host zeitserver) sollte man möglichst oft über einen längeren Zeitraum aufrufen, z.B. alle 3-4 Stunden, 24h lang (je länger, desto genauer die Messung). Bitte nicht per cron, da das Programm nicht interaktiv arbeitet und Eingaben benötigt. Die Abstände dazwischen müssen nicht unbedingt gleich sein, das ist egal.

Die manpages zu adjtimex, hwclock, etc. sind obligatorisch. Ebenso die Doku in /usr/share/doc/adjtimex/ und /usr/share/doc/util-linux/hwclock.irgendwas.

Bisher tut's. Toi-Toi-Toi...

PS: Wie man an den Logs sieht, hat mich das jetzt 3 volle Tage gekostet. *grmpf*

[[tom]]

PS: Wie man an den Logs sieht, hat mich das jetzt 3 volle Tage gekostet. *grmpf*

Bist du dir sicher? Vielleicht geht ja auch nur deine Uhr falsch. ;-)

SCNR

[TOM]

BTW: Ich weiß, der war gemein. Darfst mich virtuell steinigen. :)

[adjustman]

Respect, Respect. :) Was kannst Du denn zur Option:

Code: Select all

/usr/sbin/adjtimexconfig

sagen?

[dodolin]

Das sollte ich wirklich tun, TOM, denn das hat mich echt extrem viel Nerven gekostet und dein Kommentar hat mir jetzt sozusagen noch den Gnadenstoß obendrauf gesetzt! Aber ok, es sei dir verziehen... ;)

PS: NUR WEIL DU'S BIST! *schmatz* :lol:

[[tom]]

PS: NUR WEIL DU'S BIST! *schmatz* :lol:

Danke. :oops:

Du weißt ja, vom wem es kommt. ;-)

[TOM]

[phil]

Stimmt die Zeit nun dauerhaft bei Dir? Wie oft muß man adjtimex von Hand aufrufen? Mein Ziel ist ja nicht mich täglich einmal einzuloggen nur um die Uhrzeit zu stellen ;-)

Grüße

Phil

[dea]

dodolin, irgendwo (ich meine, es wäre d-u-g im Januar oder Februar gewesen) habe ich mal gelesen, dass es in Verbindung mit einem 2.6er Kernel zu solchen "Ausfallerscheinungen" kommt. Das liegt angeblich an einer neuen Implementierung der Kernel-Uhr. Allerdings war dieses Phänomen dort eher auf Notebooks begrenzt. IIRC hat einer auch mal einen Workaround gepostet.

Vielleicht hilft's Dir ja weiter ;)

[phil]

Ich hab 2.4.25 laufen. Die HW Uhr scheint korrekt zu gehen.

[sascha]

Das Problem tritt wohl nur bei Servern auf in denen das D1219 von Fujitsu Siemens verbaut wurde. Einzige Lösung war laut 1&1 der Austausch.

[dodolin]

Stimmt die Zeit nun dauerhaft bei Dir? Wie oft muß man adjtimex von Hand aufrufen?

Nein, ab und an krieg ich immer noch "synchronisation lost" Fehler. Ich gehe nach dem FAQ-Artikel vor, so ca. alle paar Wochen einmal, dann passts wieder ne Weile.

habe ich mal gelesen, dass es in Verbindung mit einem 2.6er Kernel zu solchen "Ausfallerscheinungen" kommt.

Ich hab 2.4.18 (gepatched), das kanns also nicht sein. Wie Sascha schon bemerkt hat, liegt das am Board, weil das kaputte Timer-Interrupts sendet.

[phil]

Das Problem tritt wohl nur bei Servern auf in denen das D1219 von Fujitsu Siemens verbaut wurde. Einzige Lösung war laut 1&1 der Austausch.

Mh das ja interessant. Gibt es ein Tool wo ich sehen könnte ob genau dieses Board bei mir verbaut ist?

Viele Grüße

Phil

[sascha]

Das kann man z.B. teilweise mit hwinfo unter SuSE oder mit dmidecode auslesen.

[mekonikum]

Das Problem tritt wohl nur bei Servern auf in denen das D1219 von Fujitsu Siemens verbaut wurde. Einzige Lösung war laut 1&1 der Austausch.

Ich kann mir auch denken wo die Boards gelandet sind nach dem Austausch ... bei Alturo. :-/
In meinem Alturo Dedi ist zufällig ein Siemens Board.

Bei meinem Alturo Dedi geht auch nach einem Boardtausch die Uhr noch pro 20min um 6sek vor, alle 20min ist nen 6sek sprung in den Logs, und der Kernel kann das nicht langsam ausgleichen.

Gibt es vielleicht eine möglichkeit den Kernel zu patchen das er größere Sprünge als die 0,5ms zu lässt?

[sascha]

Ich würde an deiner Stelle auf einwandfreie Hardware bestehen oder vom Vertrag zurücktreten.