Am Mittwoch, 24. Oktober 2007 20:58:31 schrieb Arno Lehmann:
Hi, Hi Arno, Ich fin'd das mit den Pool-Servern ja sowieso problematisch, aber nun ja... jedenfalls würde ich normalerweise immer "feste" ntp-Server vorgeben, und deine Erfahrung scheint das ja zu bestätigen.
ganz meine Meinung:-) Irgendwie traue ich den pool-servern auch nicht so, zumal "server 0.de.pool.ntp.org" nicht gefunden werden kann (wie auch-in DNS-Namen darf es ja keine Leerzeichen geben); von daher vertraue ich lieber auf die Server in BS...
Die sollte eigentlich unproblematisch sein, aber allein testhalber schon sinnvoll. Ja-man sollte alle möglichen Fehlerquellen im Voraus ausschalten... :-) Das scheint sich nur auf eine IPv6-Adresse zu beziehen. An sich sollte der ntp aber auf einer IPv4-Adresse arbeiten. Nach dem ich weiß, was IPv4/6 bedeutet, kann ich deinen Einwand nachvollziehen... Kann man irgendwo einstellen, welche IP-Version Linux verwenden soll? Wenn denn eine IPv4-Adresse benutzt wird ist das nicht weiter schlimm. Siehe oben!
24 Oct 17:24:14 ntpd[2820]: synchronized to LOCAL(0), stratum 10 24 Oct 17:24:14 ntpd[2820]: kernel time sync status change 0001 24 Oct 17:26:02 ntpd[2820]: Listening on interface #7 eth0, fe80::230:5ff:fe21:53e6#123 Enabled
Das sieht doch schon ganz gut aus. Meinst du...? Ja, doch schon... Es heisst vor allem "schlechte Verlässlichkeit" und wird, wie in diesem Fall, zur Qualifizierung der lokalen Hardware-Uhr benutzt. Um die geht es hier nämlich. Achso-allerdings habe ich mir die ntp.log nochmal angesehen und habe dabei folgendes entdeckt:
25 Oct 15:01:20 ntpd[3938]: ntpd exiting on signal 15 Wenn mich mein Englisch nicht vollkommen im Stich lässt bedeutet das doch, das der NTPD beendet wurde. Das würde auch erklären, dass die Zeit trotz einmaligem ntpdate-nach spät. 1 Stunde "Computer-Durchlauf" wieder vollkommen verstellt ist...
Abwarten... probier mal 'lsof -i -a -c ntpd', das sollte sowas: ergeben. Sprich es zeigt dass ntp auf allen IPv4-Adressen lauscht. noname:/home/christian # lsof -i -a -c ntpd COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME ntpd 3992 ntp 16u IPv4 29024 UDP *:123 ntpd 3992 ntp 17u IPv6 29025 UDP *:123 ntpd 3992 ntp 18u IPv6 29027 UDP localhost:123 ntpd 3992 ntp 19u IPv6 29028 UDP [fe80::230:5ff:fe21:53e6]:123 ntpd 3992 ntp 20u IPv4 29029 UDP localhost:123 ntpd 3992 ntp 21u IPv4 29030 UDP noname:123 Wichtiger ist - wieder - was ntp als Zeitquellen findet, also z.B. noname:/home/christian # ntpdc -c peers localhost remote local st poll reach delay offset disp ======================================================================= *LOCAL(0) 127.0.0.1 10 64 377 0.00000 0.000000 0.03043 =ptbtime2.ptb.de 192.168.178.21 1 512 377 0.02605 -30.16319 0.10597 =ptbtime1.ptb.de 192.168.178.21 1 512 377 0.02603 -25.03976 0.11348
Also findet er scheinbar Quellen...
Auch wenn noch nicht syncronisiert ist sollten die ptb-Server auftauchen. Die Syncronisierung kann schon etwas dauern. Ja, aber wie kann's sein, dass die Uhr nach ca. 2 Stunden Non-Stop Computerbetrieb ziemlich stark von der "Echtzeit" abweicht (meistens 15 Minuten)??? Das will mir nicht in den Kopf!
Arno Grüße, 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