Am Freitag, 21. Dezember 2007 13:08:05 schrieb Martin Burnicki:
Hallo Christian, Hallo Martin,
Hallo Martin,
zunächst sorry für die lange Reaktionslosigkeit von meiner Seite-musste ein Projekt fertig stellen und hatte daher keinen Nerv und keine Zeit, die vielen langen Mails zu lesen.
Danke für die ausführlichen Erklärungen bezüglich der Funktionsweise des NTPD; so kann ich mir das jetzt alles besser vorstellen. Das mache ich nun hiermit!
Nachdem ich alle deine o.g. Maßnahmen an meinem System durchgeführt habe, kann ich erstmal einen Teilerfolg vermelden:
Beim Booten wird die aktuelle Zeit mit dem NTP-Server der Uni Stuttgart (129.69.1.153) abgeglichen und "hart" korrigiert. So sind in der NTP.log die entsprechenden Erfolgsmeldungen zu finden: 19 Dec 14:24:26 ntpd[3332]: synchronized to 129.69.1.153, stratum 1 19 Dec 14:03:50 ntpd[3332]: time reset -1236.332075 s 19 Dec 14:03:50 ntpd[3332]: kernel time sync status change 0001 19 Dec 14:07:13 ntpd[3332]: synchronized to LOCAL(0), stratum 10 19 Dec 14:38:46 ntpd[3332]: ntpd exiting on signal 15 19 Dec 14:41:06 ntpd[3320]: synchronized to 129.69.1.153, stratum 1 19 Dec 14:39:37 ntpd[3320]: time reset -88.680020 s 19 Dec 14:43:08 ntpd[3320]: synchronized to LOCAL(0), stratum 10 19 Dec 14:50:13 ntpd[3320]: ntpd exiting on signal 15 19 Dec 17:46:16 ntpd[3272]: synchronized to 129.69.1.153, stratum 1 19 Dec 17:49:09 ntpd[3272]: time reset +173.121827 s 19 Dec 17:49:09 ntpd[3272]: kernel time sync status change 0001 19 Dec 17:53:23 ntpd[3272]: synchronized to LOCAL(0), stratum 10 19 Dec 19:07:51 ntpd[3272]: ntpd exiting on signal 15 19 Dec 20:40:04 ntpd[3311]: synchronized to 129.69.1.153, stratum 1 19 Dec 20:36:51 ntpd[3311]: time reset -193.205870 s 19 Dec 20:36:51 ntpd[3311]: kernel time sync status change 0001 19 Dec 20:40:39 ntpd[3311]: synchronized to LOCAL(0), stratum 10
Allerdings wird die Zeit nicht immer noch nicht in regelmäßigen Abständen überprüft was zur Folge hat, dass die Software-Uhr und die Referenzzeitquelle (also die Server) abweichen; je nachdem wie lange der Computer läuft. So ist es auf meiner Uhr inzwischen 22:09, obwohl laut uhrzeit.org erst 22:06 sein müsste. Jetzt wäre es noch klasse, wenn die Zeit während der PC läuft regelmäßig abgleicht und "weich" korrigiert würde...
Aber toll, dass NTPD zumindest beim Booten die Zeit richtig stellt.
Wenn ntpd die Zeit nicht dauerhaft synchronisieren kann, obwohl die Netzwerkverbindung besteht, kann das auf das andere Problem hindeuten, dass der Kernel in der verwendeten Timer-Konfiguration die Zeit nicht sauber weiterführen kann. Hmm... in deiner langen Erklärung vom 7.12. schriebst du, dass event. der Quarz auf dem Mainboard, der den Timer-Tick angibt, Probleme bereiten könnte.
Ich weiß ja nicht, in wiefern ich damit auf dem richtigen Dampfer bin, aber ich habe einen relativ alten PC (Fujitsu-Siemens, Scenic L 815i, Systembaugruppe D1219); im technischen Handbuch von dem Mainboard (eben das 1219) konnte ich leider nichts näheres zu dem Timer-Quarz finden, aber könnte es vielleicht daran liegen? Ich mit meinen laienhaften Linux-Kenntnissen könnte mir durchaus vorstellen, dass der Kernel-speziell mit DIESEM Mainboard- nicht klarkommt. Schließlich ist es ja ein älteres Modell, wie bereits erwähnt.
Auf der anderen Seite sind in Deinem Log oben verschiedene ntpds mit unterschiedlichen Prozeß-IDs. "time reset" gibt jeweils an, dass der ntpd die Zeit hart gestellt hat, weil die Abweichung mehr als 128 ms beträgt. Normalerweise sollte das nur kurz nach dem Start passieren. Anschließend sollte der mit "ntpq -p" angezeigt Zeitoffset _langsam_ gegen ein Minimum gehen.
Richtig! Die Zeit stellt sich beim Booten kurz "hart", dass kam in meiner letzten Mail wohl nicht ganz rüber. Sobald Suse mit Starten des X-Window-Systems fertig ist, wird mein Bildschirm kurz schwarz. Das ist der Zeitpunkt, wo die Uhr sich "hart" korriegiert. Der gezeigte Offset bewegt sich aber leider nicht gegen ein Minimum-im Gegenteil: es wird mehr! remote refid st t when poll reach delay offset jitter ============================================================================== *LOCAL(0) .LOCL. 10 l 21 64 377 0.000 0.000 0.001 rustime01.rus.u .DCFp. 1 u 437 1024 377 14.215 -30171. 26159.6 ntps1-0.cs.tu-b .PPS. 1 u 443 1024 377 24.514 -63769. 30438.3 ntp2.belwue.de .PPS. 1 u 426 1024 377 14.556 -41347. 21774.2 pc-christian:/home/christian # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *LOCAL(0) .LOCL. 10 l 60 64 377 0.000 0.000 0.001 rustime01.rus.u .DCFp. 1 u 670 1024 377 15.116 -84587. 41094.1 ntps1-0.cs.tu-b .PPS. 1 u 678 1024 377 25.444 -125382 41071.6 ntp2.belwue.de .PPS. 1 u 661 1024 377 15.315 -126059 41038.4
Zu den Logs: der ntpd seine Startup-Meldungen immer ins syslog, auch wenn ein "alternate log file" in ntp.conf eingetragen wurde. Zur Fehlersuche kann es hilfreich sein, den "alternate log file"-Eintrag auszukommentieren, damit man im Syslog alle Meldungen beisammen hat.
Wenn Du dann noch die "loopstats" freischaltest (siehe auskommentierte Einträge in ntp.conf) kann man nach einigen Stunden im loopstats-File sehen, ob ntpd die Zeitsynchronisierung hinbekommt.
Ähm... sorry, aber das ist der Punkt, an dem ich mit meinem Verständnis kapituliere. Oder einfach gesagt: Ich verstehe nur BAHNHOF! :-) Wie kommentiere ich den "alternate log file" Eintrag aus? Was ein Kommentar in Bezug auf Computertechnik ist, kann ich mir aus HTML/Java ja noch herleiten, aber was muss ich genau machen?! Und wie wird "loopstats" freigeschaltet?
Viele Grüße,
Martin
Viele Grüße aus Speyer! Christian -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org