Am Dienstag, 23. Oktober 2007 19:59:56 schrieb Thomas Schulte:

Hallo Christian, Moin Thomas, Moin Phillip,

danke für eure Antworten!

ich kann Dir zwar nicht mit einer Lösung helfen, aber vielleicht ein Hinweis, den Du möglicherweise übersehen hast:

Ich sehe in Deiner boot.msg 2x den NTPD-Start, einmal in Zeile 421/422 mit der von Dir genannten Fehlermeldung und dann nochmal beim Runlevel 5 in Zeile 484/485, hier scheint aber alles in Ordnung zu sein (grep NTPD).

Das erste Vorkommen der Meldung habe ich bei meinem openSUSE 10.3 (x86_64) auch. Danach folgt aber der einwandfreie Start im Runlevel 5: Das konnte ich jetzt auch sehen-stimmt!

Das ist ja interessant. Ich wollte jetzt mal auf Nummer sicher gehen und habe ein "rcntp status" ausgeführt und siehe da: "unused", obwohl "chkconfig ntp" mir eindeutig "on" zeigt. Habe daraufhin innerhalb meiner KDE-Session in einer Konsole als root "rcntp start" ausgeführt. Da wurden meine Bildschirme schwarz und ich dachte, es hätte mir die gesamte Session runtergerissen. Ein paar Sekunden später war aber alles wieder okay. Ob das so in Ordnung ist?!

Jetzt zeigt "rcntp status" jedenfalls "running" an. Was zeigt's denn bei Dir? Bei mir zeigte "rcntp status" bis gestern direkt nach dem Booten auch "unused" an; als ich jedoch heute morgen den Status des NTP-Clients abfrage erscheint "running"... Das ist ja wirklich merkwürdig. Also offensichtlich startet der NTP-Dämon beim Booten nun wieder-chkconfig ntp zeigt, wie bei dir, "on" an.

Bei "chkconfig -l ntpd" erscheint allerdings "ntpd: unknown service" und bei "ntpq -p" remote refid st t when poll reach delay offset jitter ============================================================================== *LOCAL(0) .LOCL. 10 l 36 64 377 0.000 0.000 0.001 laximos.fiasko. 192.53.103.104 2 u 24 64 377 13.134 -12209. 7287.45 Bleibt also festzuhalten, dass ich nun wieder bei der Grunddiskusstion bin, die ich mit Arno/Ralf bereits geführt hatte-der NTP läuft, gleicht aber die Zeit nicht ab... :-(

Gruß, Thomas 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

Am Mittwoch, 24. Oktober 2007 09:55:23 schrieb Kyek, Andreas, VF-DE: Hallo Andreas, danke für deine Rückmeldung!

Fahre deinen ntp mal runter; stelle deine PC Uhr richtig; dazu kann man AFAIK "ntpd -q" benutzen; auch hier wieder die Ausgabe in /var/log/ntp beachten.

lösche deine Drift-Datei (hier: /var/lib/ntp/drift/ntp.drift) und starte den ntp wieder.

Ferner würde ich empfehlen, mehr als einen Timeserver zu benutzen; ich habe hier --- cut here --- server 0.de.pool.ntp.org server 1.de.pool.ntp.org server 2.de.pool.ntp.org server 3.de.pool.ntp.org --- cut here ---

und KEINE Probleme mit dem ntp; weder beim starten noch beim Abgleich.

Beobachte dann mal in /var/log/ntp, was er so in der nächsten Zeit treibt. (Bis zum Abgleich kann einige Zeit vergehen; dann sollte aber eine Meldung der Art "synchronized to ..." auftauchen) Ich bin ganz genau nach deiner Anleitung vorgegangen-hat aber nichts gebracht. Ich vermute nach ein wenig Googlen das Problem woanders:

Habe inzwischen die pool.ntp-server durch die Zeitserver der PTB in Braunschweig (Atomuhr) testweise ersetzt, sowie die Linux-Firewall ausgeschaltet. Nun erscheint in der NTP-Log Datei aber folgendes: 24 Oct 17:15:18 ntpd[2935]: Listening on interface #6 eth0, fe80::230:5ff:fe21:53e6#123 Enabled 24 Oct 17:18:29 ntpd[2935]: synchronized to LOCAL(0), stratum 10 24 Oct 17:18:29 ntpd[2935]: kernel time sync status change 0001 24 Oct 17:19:31 ntpd[2935]: ntpd exiting on signal 15 24 Oct 17:21:02 ntpd[2820]: bind() fd 21, family 10, port 123, scope 2, addr fe80::230:5ff:fe21:53e6, in6_is_addr_multicast=0 flags=0x11 fails: Cannot assign requested address 24 Oct 17:21:02 ntpd[2820]: unable to create socket on eth0 (6) for fe80::230:5ff:fe21:53e6#123 24 Oct 17:21:02 ntpd[2820]: failed to initialize interface for address fe80::230:5ff:fe21:53e6 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 Besonders die Zeile 24 Oct 17:24:14 ntpd[2820]: synchronized to LOCAL(0), stratum 10 macht mich stutzig! "Stratum 10" bedeutet ja (laut Google) "schlechte Verbindung". Also stimmt irgendwas mit meiner Verbindung nicht. Dabei haben wir hier DSL und der Router läuft Tag und Nacht! Das verstehe ich einfach nicht! Anbei noch die gesamte NTP-Log Datei. Wer kann in Bezug auf "Stratum 10" noch etwas geistreiches beisteuern? Grüße, Christian

Hi, 24.10.2007 18:22,, Christian Pubanz (GMX) wrote::

Am Mittwoch, 24. Oktober 2007 09:55:23 schrieb Kyek, Andreas, VF-DE: Hallo Andreas, danke für deine Rückmeldung!

...

Fahre deinen ntp mal runter; stelle deine PC Uhr richtig; dazu kann man AFAIK "ntpd -q" benutzen; auch hier wieder die Ausgabe in /var/log/ntp beachten.

lösche deine Drift-Datei (hier: /var/lib/ntp/drift/ntp.drift) und starte den ntp wieder.

Ferner würde ich empfehlen, mehr als einen Timeserver zu benutzen; ich habe hier --- cut here --- server 0.de.pool.ntp.org server 1.de.pool.ntp.org server 2.de.pool.ntp.org server 3.de.pool.ntp.org --- cut here ---

und KEINE Probleme mit dem ntp; weder beim starten noch beim Abgleich.

Beobachte dann mal in /var/log/ntp, was er so in der nächsten Zeit treibt. (Bis zum Abgleich kann einige Zeit vergehen; dann sollte aber eine Meldung der Art "synchronized to ..." auftauchen) Ich bin ganz genau nach deiner Anleitung vorgegangen-hat aber nichts gebracht. Ich vermute nach ein wenig Googlen das Problem woanders:

Habe inzwischen die pool.ntp-server durch die Zeitserver der PTB in Braunschweig (Atomuhr) testweise ersetzt,

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.

sowie die Linux-Firewall ausgeschaltet.

Die sollte eigentlich unproblematisch sein, aber allein testhalber schon sinnvoll.

Nun erscheint in der NTP-Log Datei aber folgendes:

24 Oct 17:15:18 ntpd[2935]: Listening on interface #6 eth0, fe80::230:5ff:fe21:53e6#123 Enabled 24 Oct 17:18:29 ntpd[2935]: synchronized to LOCAL(0), stratum 10 24 Oct 17:18:29 ntpd[2935]: kernel time sync status change 0001 24 Oct 17:19:31 ntpd[2935]: ntpd exiting on signal 15 24 Oct 17:21:02 ntpd[2820]: bind() fd 21, family 10, port 123, scope 2, addr fe80::230:5ff:fe21:53e6, in6_is_addr_multicast=0 flags=0x11 fails: Cannot assign requested address

Das scheint sich nur auf eine IPv6-Adresse zu beziehen. An sich sollte der ntp aber auf einer IPv4-Adresse arbeiten.

24 Oct 17:21:02 ntpd[2820]: unable to create socket on eth0 (6) for fe80::230:5ff:fe21:53e6#123 24 Oct 17:21:02 ntpd[2820]: failed to initialize interface for address fe80::230:5ff:fe21:53e6

Wenn denn eine IPv4-Adresse benutzt wird ist das nicht weiter schlimm.

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.

Besonders die Zeile 24 Oct 17:24:14 ntpd[2820]: synchronized to LOCAL(0), stratum 10 macht mich stutzig! "Stratum 10" bedeutet ja (laut Google) "schlechte Verbindung".

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.

Also stimmt irgendwas mit meiner Verbindung nicht. Dabei haben wir hier DSL und der Router läuft Tag und Nacht! Das verstehe ich einfach nicht!

Abwarten... probier mal 'lsof -i -a -c ntpd', das sollte sowas: neuelf:~ # lsof -i -a -c ntpd COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME ntpd 3684 ntp 16u IPv4 13670 UDP *:123 ntpd 3684 ntp 17u IPv4 13672 UDP localhost:123 ntpd 3684 ntp 18u IPv4 13673 UDP neuelf.y.z.de:123 ergeben. Sprich es zeigt dass ntp auf allen IPv4-Adressen lauscht.

Anbei noch die gesamte NTP-Log Datei.

Wer kann in Bezug auf "Stratum 10" noch etwas geistreiches beisteuern?

Das ist nur die lokale Uhr. Wichtiger ist - wieder - was ntp als Zeitquellen findet, also z.B. neuelf:~ # ntpdc -c peers localhost remote local st poll reach delay offset disp ======================================================================= =ptbtime2.ptb.de 192.168.0.7 1 64 0 0.02827 -0.003978 3.99217 =ptbtime1.ptb.de 192.168.0.7 1 64 0 0.02972 -0.003291 3.99217 *balrog.y.z.de 192.168.0.7 2 1024 377 0.00020 -0.000352 0.13666 Auch wenn noch nicht syncronisiert ist sollten die ptb-Server auftauchen. Die Syncronisierung kann schon etwas dauern. Arno

Grüße, Christian

-- Arno Lehmann IT-Service Lehmann www.its-lehmann.de -- 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

Christian Pubanz (GMX) wrote:

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...

Sorry, aber du hast was ganz derbe verwechselt: die Zeile --- cut here --- server 0.de.pool.ntp.org --- cut here --- gehört so in die /etc/ntp.conf; der Servername ist natürlich nur 0.de.pool.ntp.org und den kannst du wunderbar abfragen! Du wirst immer wieder andere Adressen erhalten; das ist ja gerade der Sinn der pool Server: Der DNS verteilt die Anfragen an alle Server im Pool! Und ich finde es gelinde gesagt nicht nett, direkt die Server der ptb anzusprechen. Ist IMO das gleiche wie das direkte Ansprechen der root-DNS: machen das alle, gehen die Dinger in die Knie. Die ntp Server der ptb sollen als stratum1 Server nicht von jedem x-beliebigen angesprochen werden sondern eine Reihe von stratum2 Servern versorgen usw. (Steht glaube ich sogar irgendwo auf deren Web-Seiten) Zum Test kann man AFAIK die mal kurz hernehmen; aber es bringt dir keine Vorteile: Die pool Server funktionieren auf allen mir bekannten Servern einwandfrei und die sind explizit für die Allgemeinheit freigegeben. Und die Uhr stellen die anderen auch genau genug! Just my two cents! Andreas -- 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

Am Donnerstag, 25. Oktober 2007 20:02:28 schrieb Jan Ritzerfeld: Hallo!

100% Full ACK! :-D

Provider wie T-Online, Freenet, Netcologne und Unis haben auch eigene Time-Server. Erfolgreiche Kandidaten sind sowas wie ntp, ntp1 oder timeserver mit der Domain des Providers angehangen. Ansonsten Tante Google nach "timeserver $providername" oder "ntp $providername" fragen.

Meine Güte-ich wollte das Thema jetzt nicht "hochkochen"-man kann auch mehr daraus machen, als es wirklich ist! ;-) Das mit den PTB-Servern war mehr als "Randbemerkung" gedacht, sollte aber nicht zum "Hauptdiskussionsthema" werden... Gruß, 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

Hi ! Derzeit kaempfe ich auch mit NTP (allerdings um den richtigen Treiber fuer meine Uhr zu finden).... Bei mir bleibt aber die Zeit derzeit einfach stehn.... Ich habe gestern alles eingestellt und heute abend wenn ich heim komme steht bzw. laeuft die Uhr bei 08 Uhr irgendwas ... ================================= Wer kann in Bezug auf "Stratum 10" noch etwas geistreiches beisteuern? ================================ Zur Beurteilung der Qualität einer Uhrzeit wird ein Qualitätsmerkmal geführt, das STRATUM. Ein STRATUM von 1 haben alle Rechner, die ihre Zeit direkt von einer autorisierten Quelle wie etwa einer Funkuhr beziehen. Rechner, die ihre Uhrzeit über einen im Internet erreichbaren Zeitserver synchronisieren, haben ein STRATUM von 2. Ein STRATUM-3-Rechner bezieht seine Zeit von einem STRATUM 2 Rechner und so weiter bis zu allen Rechnern, deren Uhrzeit überhaupt nicht synchronisiert ist (diese erhalten den maximal möglichen Wert STRATUM 16 UND Das Stratum dient dem Netzwerk der Zeitserver als Identifikation der Wichtigkeit. bzw. Nähe eines Servers zu einer Zeitquelle. Sorry fuer den langen footer, aber sobald daheim wieder alles eingerichtet ist stell ich wieder um :-) Ciao Gerd ==================================================================================== TAKATA-PETRI AG - Bahnweg 1 - 63743 Aschaffenburg, Germany Aufsichtsratsvorsitzender: Shigehisa Takada Vorstand: Dr. Heinrich Binder (Vorsitzender), Rolf Pfoh, Yoichiro Nomura HR Amtsgericht Aschaffenburg HRB 120 The contents of this e-mail and attachments are confidential and for your eyes only. Do not copy, retransmit, or share this information with anyone unless absolutely required for specific business purposes. If you are not the intended recipient of this email, any disclosure, copying, distribution or use of its contents is strictly prohibited. Please notify the sender immediately and delete this message and attachments from your system. ==================================================================================== -- 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

Am Donnerstag, 25. Oktober 2007 21:26:15 schrieb Martin Hofius: Hallo opensuse-de,

Da gibt es doch immer noch die Datei /etc/adjtime, in der die Abweichung der Hardwareuhr von der neu eingestellten Zeit festgehalten wird. Da könnte evtl. ein ziemlich unsinniger Wert drinstehen, der dann die "Softwareuhr" extrem schnell oder langsam gehen läßt. Ich würde die Datei einfach mal löschen... (oder im Zweifel einfach umbenennen).

Ich habe von mir und meinem ominösen Problem mit dem NTP-Dämon lange nichts mehr hören lassen. Aber seit heute habe ich eine neue heiße Spur. Ich benutze nun statt der PTB-Server die NTP-Server von der Uni Stuttgart, der TU Berlin, sowie vom Baden-Württembergischen Dienst BELWUE. Den Pool-NTP kann ich leider nicht verwenden (Fehlermeldung:Temporary failed in name resulution); dies erstmal vorweg. Inzwischen habe ich es soweit hinbekommen, dass beim Booten der NTPD startet, sich von einem der og. Server die aktuelle Uhrzeit holt (Try to get initial date and time via NTP) und abgleicht. Also geht direkt nach dem Booten die Uhr korrekt. Allerdings fiel mir auf, dass der Offset immer höher wird, je länger der Rechner läuft. noname:/home/christian # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== LOCAL(0) .LOCL. 10 l 6 64 3 0.000 0.000 0.001 rustime01.rus.u .DCFp. 1 u 4 64 3 14.226 -2188.9 2122.22 ntps1-0.cs.tu-b .PPS. 1 u 5 64 3 25.897 -2155.0 2057.12 ntp2.belwue.de .PPS. 1 u 5 64 3 14.805 -2156.0 2025.82 noname:/home/christian # hwclock -w noname:/home/christian # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *LOCAL(0) .LOCL. 10 l 48 64 77 0.000 0.000 0.001 rustime01.rus.u .DCFp. 1 u 49 64 77 14.226 -2188.9 5134.66 ntps1-0.cs.tu-b .PPS. 1 u 50 64 77 24.447 -4246.2 4031.49 ntp2.belwue.de .PPS. 1 u 49 64 77 14.489 -130.20 6833.54 noname:/home/christian # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *LOCAL(0) .LOCL. 10 l 15 64 377 0.000 0.000 0.001 rustime01.rus.u .DCFp. 1 u 18 64 377 14.226 -2188.9 9570.49 ntps1-0.cs.tu-b .PPS. 1 u 16 64 375 24.447 -4246.2 6911.75 ntp2.belwue.de .PPS. 1 u 14 64 377 14.805 -2156.0 9703.05 noname:/home/christian # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *LOCAL(0) .LOCL. 10 l 45 64 377 0.000 0.000 0.001 rustime01.rus.u .DCFp. 1 u 246 512 377 14.431 -22455. 19257.8 ntps1-0.cs.tu-b .PPS. 1 u 242 512 355 23.802 -20059. 18142.6 ntp2.belwue.de .PPS. 1 u 180 512 377 13.927 -20109. 22938.2 noname:/home/christian # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *LOCAL(0) .LOCL. 10 l 29 64 377 0.000 0.000 0.001 rustime01.rus.u .DCFp. 1 u 48 1024 377 14.506 -79302. 39097.8 ntps1-0.cs.tu-b .PPS. 1 u 48 1024 267 25.536 -79411. 38987.9 ntp2.belwue.de .PPS. 1 u 1009 1024 377 14.755 -34790. 24084.4 noname:/home/christian # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *LOCAL(0) .LOCL. 10 l 62 64 377 0.000 0.000 0.001 rustime01.rus.u .DCFp. 1 u 340 1024 377 14.506 -79302. 39097.8 ntps1-0.cs.tu-b .PPS. 1 u 340 1024 267 25.536 -79411. 38987.9 ntp2.belwue.de .PPS. 1 u 275 1024 377 14.947 -81939. 38831.0 Die ntp log schreibt unterdessen 17 Nov 17:55:26 ntpd[2783]: Cannot find existing interface for address 129.69.1.153 17 Nov 17:55:26 ntpd[2783]: configuration of 129.69.1.153 failed 17 Nov 17:55:26 ntpd[2783]: Cannot find existing interface for address 130.149.17.21 17 Nov 17:55:26 ntpd[2783]: configuration of 130.149.17.21 failed 17 Nov 17:55:26 ntpd[2783]: Cannot find existing interface for address 129.143.2.33 17 Nov 17:55:26 ntpd[2783]: configuration of 129.143.2.33 failed 17 Nov 17:55:26 ntpd[2783]: Listening on interface #2 eth0, 192.168.178.22#123 Enabled 17 Nov 17:55:28 ntpd[2783]: ntpd exiting on signal 15 17 Nov 17:58:37 ntpd[2916]: synchronized to LOCAL(0), stratum 10 17 Nov 17:58:37 ntpd[2916]: kernel time sync status change 0001 17 Nov 18:54:54 ntpd[2916]: ntpd exiting on signal 15 17 Nov 18:55:48 ntpd[2803]: ntpd exiting on signal 15 17 Nov 18:59:03 ntpd[2896]: synchronized to LOCAL(0), stratum 10 17 Nov 18:59:03 ntpd[2896]: kernel time sync status change 0001 Verstehe ich das richtig, dass der NTPD die Server nur quasi beim Booten findet, dann aber nicht mehr, deswegen der Offset immer höher wird und der NTP sich beendet? Habe noch bei OpenSuse einen Artikel gefunden-kann das damit zusammenhängen? (Bezug auf hwclock) http://de.opensuse.org/SDB:Zeit_%C3%BCber_das_Netz_einstellen_lassen Grüße, Danke und schönes Wochenende! 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

Am Sonntag, 18. November 2007 schrieb Christian Pubanz (GMX):

(...).

...

Spontan kam mir auch noch die Idee, dass es event. auch am KNetworkmanager liegen könnte. Ich bin ja über Eathernet an eine FRITZBOX angschlossen, die Verbindung/IP-Zuweisung nimmt ja der KNetworkmanager vor und der startet bei mir erst im X-Window-System. Oder ist das ne ganz falsche Vermutung? (...).

Ich frag mich auch, was da so falsch läuft. Nachdem ich mich angemeldet habe läuft kein ntpd. Jedenfalls kann ich mich nicht mit xntpdc zu ihm verbinden. Während des Bootens erscheint die Meldung, daß ntpdate den Zeit-Server nicht finden kann. Der ntpd selbst wird zwar gestartet, aber ziemlich zeitnah wieder beendet. Den entsprechenden Bugreports kann ich entnehmen, daß es normal ist, daß ntpdate und ntpd beim ersten Aufruf nicht funktionieren. Wenn dann tatsächlich eine Verbindung aufgebaut wurde, sollten die beiden einfach nochmal durch /etc/sysconfig/network/if-up.d/50-ntp gestartet werden. ntpdate wird bei mir auch ein zweites mal ausgeführt, aber der zweite ntpd stirbt mit "parent died before we finished, exiting". https://bugzilla.novell.com/show_bug.cgi?id=256291 Gruß Jan -- The greatest American superstition is the belief in facts. -- 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

Am Dienstag, 20. November 2007 15:28:31 schrieb Ralf Arndt: Hallo Ralf,

Hast Du das mittlerweile mal versucht? Im folgenden finde ich keinen Hinweis darauf. ja, ich habe es versucht, aber das war nicht das Problem. Obwohl ich die Datei gelöscht habe, hat es keine Veränderung gebracht. Fehler bei der Namensauflösung. Liegt vermutlich daran, dass Du den NetworkManager benutzt und erst mit der Anmeldung ein Netz bekommst (siehe Deine neueren Mails). Ich denke, mit diesen NTP-Servern "fahre" ich ganz gut, da diese öffentlich und für jedermann frei verfügbar sind. Außerdem habe ich die konkreten IP-Adressen eingetragen-das ist günstiger.

Weiter habe ich den KNetworkmanager seit einigen Tagen deaktiviert und nehme die ifup-Methode (testweise).

Das macht er eben nicht, s.u. Leider doch! Denn direkt nach dem Booten ist die Uhr syncron zur Funkzeit-erst wenn der PC eine längere Zeit läuft, laufen beide Zeitangaben auseinander. Sprich: wenn nach dem Booten die Uhr richtig läuft, wird die doch Ihre Uhrzeit irgendwo her haben... Gehe bitte mal beim booten in das BIOS Setup und schau nach, ob die Uhr richtig geht. Damit kann ich momentan leider nicht dienen; bei mir spinnt derzeit mein Monitor/Grafikkarte-jedenfalls komme ich derzeit nicht ins BIOS! Klingt komisch-ist aber so! :-D Der Stern vor der Zeile bedeutet AFAIK, dass er sich mit der jeweiligen Quelle synchronisiert hat. Das ist bei Dir immer die lokale Uhr (*LOCAL(0)). Mit den anderen Quellen hat keine Synchronisierung stattgefunden.

Setze mal bei bestehender Netzwerkverbindung ein rcntp restart ab und beobachte mal das Log. Das mache ich mal-Bericht darüber in der nächsten Mail! Nach meiner Erfahrung sieht es eher so aus, dass die erste Synchronisation nach dem Start des Rechners (fast) immer fehlschlägt. Dies auch bei der traditionellen Methode mit ifup, also auch ohne NetworkManager. Nach einiger Zeit holt der ntp client sich dann die korrekte Zeit. Hmm... Ich sehe das genau anders rum :-) Der Zeitabgleich beim Booten funktioniert wohl-(Uhr geht ja nach dem Booten richtig)-aber dann beendet sich der NTPD wohl aus irgendwelchen Gründen, weswegen er auch keine Zeit abgleicht und die Uhren je nach Laufzeit der einzelnen Session auseinander gehen (zeitlich gesehen).

Was sagt denn ein ntpdate ntp1.ptb.de bei nicht laufendem ntpd? Falls ntpd läuft muss der vorher mit rcntp stop beendet werden. der einfache NTPDATE-Aufruf funktioniert tadellos-das habe ich schon sehr oft gemacht! ntpdate <IP/Serveradresse) tut seinen Dienst, wie es soll!

Das hatte ich (glaube ich) schonmal gefragt: Hast Du ein Dualboot System mit Windows. Nein, das hattest du bisher noch nicht gefragt. Ich habe Linux/Windows zur Auswahl (Windows für Video/Sound-Anwendungen)-falls das mit "Dual-Boot" gemeint war. Davor startet GRUB zur Systemauswahl.

Also kurz zusammengefasst: So wie ich das sehe, holt er sich beim Booten die Zeit von einem der drei Server, gleicht ab und dann wird NTPD beendet (Steht auch so in der NTP.log-siehe Anhang) Ich sehe in der Mailingliste manchmal, dass auch hier Mitarbeiter von SUSE direkt posten-vielleicht hat jemand von dort eine Idee-event. ist das ja auch schlicht ein Bug im NTPD-aber das ist nur so eine Spekulation von mir... Viele Grüße und bis zum nächsten Bericht! Christian

Am Mittwoch, 21. November 2007 00:16:52 schrieb Ralf Arndt:

Hi Christian, Hi Ralf,

Es ist zwar gut, überflüssiges aus seiner Antwort zu löschen. Man sollte aber noch darauf achten, dass der Zusammenhang erkennbar bleibt. Ich habe mal versucht, den sinngemäß wieder einzufügen. sorry! Ich weiß immer nicht, was noch relevant zum Helfen ist und was nicht. Ich versuche, mich zu bessern... ;-) [gelöschte Fehlermeldung von ntp(d)]

...

...

Fehler bei der Namensauflösung. Liegt vermutlich daran, dass Du den NetworkManager benutzt und erst mit der Anmeldung ein Netz bekommst (siehe Deine neueren Mails).

Ich denke, mit diesen NTP-Servern "fahre" ich ganz gut, da diese öffentlich und für jedermann frei verfügbar sind. Außerdem habe ich die konkreten IP-Adressen eingetragen-das ist günstiger.

1. Du fährts _nicht_ gut, weil Du eben _keine_ Zeit von den NTP Servern bekommst oder Dein Client die Zeit nicht akzeptiert. Die Ursache muss (und wird wie ich vermute) aber nicht an den Servern liegen.

2. Fehler in der Namensauflösung liegen auf einer anderen Ebene. Wenn kein Netz verfügbar ist, ist es egal, ob Du den Server über Aliasnamen oder über IP Adresse ansprichst.

Abgesehen davon: IP Adressen können sich schneller ändern als Hostnamen. Aber das ist wohl nicht Dein konkretes Problem. Richtig! Ich wäre ja überhaupt froh, wenn der NTPD arbeiten würde, was er aber nicht tut! [gelöscht: Client holt sich angeblich Zeit vom ntp Server]

...

...

Das macht er eben nicht, s.u.

Leider doch! Denn direkt nach dem Booten ist die Uhr syncron zur Funkzeit-erst wenn der PC eine längere Zeit läuft, laufen beide Zeitangaben auseinander. Sprich: wenn nach dem Booten die Uhr richtig läuft, wird die doch Ihre Uhrzeit irgendwo her haben...

NEIN EBEN NICHT (Sorry an alle aber ich brülle hier zum ersten mal). @Christian: Deine von Dir leider gelöschte Ausgabe von "ntpq -p" zeigt. dass mit Deiner lokalen Uhr synchronisiert wird und _nicht_ mit einem ntp Server. OKAY, OKAY, OKAY :-)

Du hast ja Recht-ich habs heute abend auch gemerkt, da wich die PC-Uhr von der richtigen Zeit ca. 4 Minuten ab. Daher: ICH NEHME ALLES ZURÜCK!!!! (So jetzt hab ich ne heisere Kehle :-D )

...

...

Gehe bitte mal beim booten in das BIOS Setup und schau nach, ob die Uhr richtig geht.

Damit kann ich momentan leider nicht dienen; bei mir spinnt derzeit mein Monitor/Grafikkarte-jedenfalls komme ich derzeit nicht ins BIOS! Klingt komisch-ist aber so! :-D

Schade

Inzwischen komm ich wieder ins BIOS (hab den Bildschirm ausgetauscht) und konnte da feststellen, dass die Uhr ca. 6 Minuten vorgeht-hab sie dort gleich richtig gestellt. BIOS-Batterie hab ich übrigens vor nem guten Jahr erneuert-an der kann's also auch nicht liegen...

...

...

[...] Nach meiner Erfahrung sieht es eher so aus, dass die erste Synchronisation nach dem Start des Rechners (fast) immer fehlschlägt. Dies auch bei der traditionellen Methode mit ifup, also auch ohne NetworkManager. Nach einiger Zeit holt der ntp client sich dann die korrekte Zeit.

Hmm... Ich sehe das genau anders rum :-) Der Zeitabgleich beim Booten funktioniert wohl-(Uhr geht ja nach dem Booten richtig)-aber dann beendet sich der NTPD wohl aus irgendwelchen Gründen, weswegen er auch keine Zeit abgleicht und die Uhren je nach Laufzeit der einzelnen Session auseinander gehen (zeitlich gesehen).

Ich gehe eher davon aus, dass Dein System der Meinung ist, die korrekte lokale zeit (Deiner BIOS Uhr) koprrigieren zu müssen.

Einleuchtend! Aber dann hat das System einen Denkfehler (vielleicht doch ein Bug-nur mit meinem PC reproduzierbar... Hab da mal sowas gelesen...)

...

...

Was sagt denn ein ntpdate ntp1.ptb.de bei nicht laufendem ntpd? Falls ntpd läuft muss der vorher mit rcntp stop beendet werden.

der einfache NTPDATE-Aufruf funktioniert tadellos-das habe ich schon sehr oft gemacht! ntpdate <IP/Serveradresse) tut seinen Dienst, wie es soll!

Dann schicke doch bitte mal die Ausgabe.

25 Nov 23:15:23 ntpdate[4810]: step time server 192.53.103.108 offset -363.490977 sec

...

...

Das hatte ich (glaube ich) schonmal gefragt: Hast Du ein Dualboot System mit Windows.

Nein, das hattest du bisher noch nicht gefragt. Ich habe Linux/Windows zur Auswahl (Windows für Video/Sound-Anwendungen)-falls das mit "Dual-Boot" gemeint war. Davor startet GRUB zur Systemauswahl.

Genau das habe ich gemeint. Es gibt haufenweise Threads auf der Liste zu Problemen mit Zeit und Dual Boot Systemen (Windows + Linux). Such mal danach.

Ich hab nichts gefunden in der Liste... Hab ntp+dualboot+problem eingegeben und da kam nix! Kannst du mir vielleicht ein paar Beispiellinks geben ?

...

und dann wird NTPD beendet (Steht auch so in der NTP.log-siehe Anhang)

Ich sehe in der Mailingliste manchmal, dass auch hier Mitarbeiter von SUSE direkt posten-vielleicht hat jemand von dort eine Idee-event. ist das ja auch schlicht ein Bug im NTPD-aber das ist nur so eine Spekulation von mir...

Also ich selber und anscheinend die meisten Leute auf der Liste können das Problem nicht nachvollziehen. Daher schätze ich mal, dass es sich nicht um einen bug handelt. s.o.

Gute Nacht Ralf

Ebengleich! 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

Am Donnerstag, 29. November 2007 23:34:07 schrieb Ralf Arndt: Guten Morgen Ralf,

Hallo Christian,

ich hoffe Du hast Deine Kehle wieder kuriert;-) ja, hab ich :-) Mit heißem Tee ist alles heilbar! ;-)

Es war neulich reichlich spät, ich war gestresst, und ich hätte nicht sofort antworten sollen. Das war einfach ein Verstoß gegen die netiquette. Hmm... Also mich hast du mit deiner vorherigen Antwort überhaupt nicht verärgert oder so... Wollte das nur klarstellen...

Kann dich aber gut verstehen-ich mach auch manchmal Dinge, für dich ich mich danach ohrfeigen könnte! Also: alles halb so wild! ;-)

Jetzt ist es wieder spät. Ich werde mir Deine Antworten ein anderes mal ansehen und detailliert darauf eingehen.

Okay! Freue mich schon darauf-hoffentlich kriegen wir gemeinsam den NTPD vor Weihnachten *lol' noch zum Laufen!

Gute Nacht Ralf.

Hatte ich gehabt-dir einen schönen Tag und ein stressfreies Wochenende! 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

Hallo miteinander, Jan Ritzerfeld schrieb:

Am Freitag, 30. November 2007 schrieb Christian Pubanz (GMX):

...

(...).

Über einen nicht-synchronisieren-wollenden ntp gibt es zur Zeit einen Thread auf dem englischsprachigen Pendant zu dieser Liste: http://lists.opensuse.org/opensuse/2007-12/msg00357.html

Und natürlich auch einen Bugreport: https://bugzilla.novell.com/show_bug.cgi?id=344356

Vielleicht hat das ja was mit deinem Problem gemein ...

Jein, es handelt sich wahrscheinlich um 2 Probleme. Vielleicht zunächst einige Informationen zur Funktionsweise von NTP, der Systemzeit, und einigen in diesem Thread gemachten Vermutungen. NTP und hwclock haben zunächst mal nichts miteinander zu tun. Die batteriegepufferte Uhr des Mainboards (RTC oder auch CMOS-Uhr genannt) wird nur benötigt, um die Zeit weiterzuführen, während der Rechner ausgeschaltet ist. Wenn das Betriebssystem bootet, wird die aktuelle Zeit aus der RTC gelesen und damit die Software-Uhr des Betriebssystems initial gesetzt. Das ist bei Linux, Windows und anderen aktuellen Betriebssystemen so. Danach wird normalerweise die Zeit ausschließlich als Software-Uhr weitergezählt, d.h., ein Timer auf dem Mainboard erzeugt periodische Interrupts (Timer Ticks), und bei jedem Tick wird die Zeit um einen gewissen Betrag (tickadj) weitergezählt. Beim Herunterfahren schreibt Linux die aktuelle Software-Zeit wieder zurück in die RTC, siehe Meldungen auf der Konsole. Optional kann der Kernel auch zyklisch z.B. alle paar Minuten die RTC setzen. Die Systemzeit (Software-Zeit) wird als UTC-Zeit (früher auch GMT genannt) geführt. Die auf dem Monitor angezeigte Zeit Ortszeit wird aus der UTC-Zeit berechnet, indem zu der UTC-Zeit ein Offset addiert wird, dessen Wert von der eingestellten Zeitzone abhängt und davon, ob gerade Sommerzeit ist oder nicht. Für Mitteleuropa gilt z.B.: Winterzeit MEZ = UTC + 1h Sommerzeit MESZ = UTC + 2h Unter Linux kann man den Unterschied schön sehen, wenn man an der Konsole eingibt: date; date -u Am sinnvollsten wäre es, wenn die RTC immer auf UTC-Zeit laufen würde, da das Betriebssystem dann einfach die RTC-Zeit als initiale Zeit für die Software-Uhr verwenden könnte, die dann korrekt in Ortszeit umgewandelt werden könnte. Speziell auf Multi-Boot-Systemen mit Windows (z.B. Windows 2000, aktuellere Versionen evt. nicht mehr) wird die RTC oft durch Windows auf die Ortszeit gesetzt. Wenn dann Linux gebootet wird, muss die RTC-Zeit zunächst wieder auf UTC zurückgerechnet werden. openSUSE Linux fragt bei der Installation ab, ob die RTC auf Ortszeit läuft. Um sich Probleme zu ersparen, sollte diese Option nicht markiert werden, es sei denn, ein Dual-Boot mit Windows erfordert es. Probleme mit der falschen Zeit um Beginn/Ende der Sommerzeit herum sind darauf zurückzuführen, dass entweder bei einem Multi-Boot-System das eine Betriebssysteme erwarten, dass die RTC auf Ortszeit läuft, das andere dagegen UTC erwartet, oder generell, dass die RTC auf Ortszeit läuft. Angenommen, am Abend vor der Zeitumstellung auf Winterzeit wird die RTC beim Herunterfahren mit der aktuellen Sommerzeit UTC+2h gesetzt. Am nächsten Morgen wird der Rechner wieder hochgefahren. Die RTC läuft immer noch auf UTC+2h, aber Linux "sieht", dass bereits Winterzeit ist, erwartet UTC+1h und stellt somit seine initiale Zeit um 1h verkehrt. Wenn die RTC auf UTC läuft und die Linux-Einstellung dem entspricht, können solche Probleme nicht auftreten. Zurück zur Software-Uhr und NTP. Der Quarz auf dem Mainboard, der den Timer für die Software-Uhr antreibt, weicht immer mehr oder weniger von seiner Sollfrequenz ab, d.h. die Systemzeit driftet mehr oder weniger schnell weg. Die Frequenzabweichung ist zudem stark temperaturabhängig. NTP holt sich in bestimmten Abständen die Zeit von einer Referenzzeitquelle, bestimmt dabei den Zeitoffset und auch die Frequenzabweichung, und versucht, beide so gut wie möglich zu kompensieren. Als Referenzzeitquelle kommen dabei sowohl Funkuhren/GPS-Empfänger in Frage, als auch ein oder mehrere NTP-Server im Netzwerk. Bei Letzteren versucht NTP, so gut es geht die Paketlaufzeit zu ermitteln und zu kompensieren. Ob dabei direkt die NTP-Server der PTB angesprochen werden oder die Pool-Server, spielt für die Funktionsweise grundsätzlich keine Rolle. Eine Ausnahme ist natürlich, wenn ein Pool-Server nicht korrekt arbeitet. Durch Verwendung mehrere Poolserver wie bei openSUSE 10.3 üblich wird ein "Falseticker" durch den NTP-Daemon erkannt und ignoriert. Wichtig ist, dass sich die Zeitquelle als "synchron" zu erkennen gibt, da sie sonst durch die Clients nicht akzeptiert wird. Als Zusatzfunktion arbeitet ntpd standardmäßig auch als Server, d.h. er kann seine synchronisierte Systemzeit anderen NTP-Clients im Netz zu Verfügung stellen. Um den "Abstand" zur obersten Zeitquelle anzugeben, wird der "Stratum"-Wert verwendet. Stratum-1-Server sollten eine möglichst genaue Funkuhr als Zeitquelle zur Verfügung haben. Ein Rechner, der sich auf einen Stratum-1-Server synchronisiert, wird selbst zum Stratum-2-Server, usw. Da die Weiterführung der Systemzeit im Kernel erfolgt, kann der NTP-Daemon lediglich die Korrekturwerte bestimmen. Die ermittelten Differenzen zu den Zeitquellen werden dabei durch einen ausgeklügelten Filteralgorithmus geschickt, um Ausreißer zu identifizieren und zu verwerfen. Die gefilterten Korrekturwerte werden dann an den Kernel übergeben, der dafür zuständig ist, diese anzubringen und damit die Systemzeit nachzuführen. Auf diese Weise wird die Frequenzdrift kontinuierlich derart kompensiert, dass größere Zeitabweichungen gar nicht erst auftreten. Auf welche Weise das geschieht, hängt davon ab, welches Timer Tick-Intervall verwendet wird, welcher Timer des Mainboards verwendet wird, ob der Timer durch den Kernel vollständig und korrekt unterstützt wird, usw. Bei aktuellen Chipsätzen kann es damit Probleme geben, wenn z.B. aus Energiespargründen der Takt der CPU oder des Timers heruntergesetzt wird und das beim Anbringen der Korrektur nicht korrekt berücksichtigt wird. Die ermittelte Frequenzabweichung speichert ntpd optional in dem sogenannten Driftfile, damit er beim nächsten Start wieder eingelesen werden kann und damit die Sychronisierung beschleunigt wird. Der absolute Wert im Driftfile gibt keinen Aufschluß über die Genauigkeit der Zeitnachführung, sondern zeigt lediglich, wie weit die tatsächliche Taktfrequenz des Timers vom Sollwert abweicht. Hierbei handelt es sich um ein Merkmal dieses individuellen Quarzes, d.h. er unterscheidet sich von einem Board zum anderen, je nach Quarz. Wenn die dauerhafte Zeitsynchronisierung mit einer älteren Linux-Version problemlos funktioniert hat, mit der aktuellen Version auf der gleichen Hardware aber nicht, ist das ein Indiz für unzureichende Unterstützeung des verwendeten Timers durch den Kernel. Gerade um 2.6.21 herum wurde der Timer-Code im Kernel stark verändert. Hinweise auf sderartige Probleme sind Jan's zitierte Quellen (s.o.) oder auch entsprechende Meldungen in der NTP-Newsgroup, z.B.: http://groups.google.de/groups?as_epq=opensuse+10.3&as_ugroup=comp.protocols.time.ntp Zum Problem mit NTP beim Booten von openSUSE 10.3: Es handelt sich dabei um ein Problem mit den Init-Scripten. Siehe auch: https://bugzilla.novell.com/show_bug.cgi?id=337075 Der NTP-Daemon beendet sich selbst mit einer entsprechenden Meldung im Syslog, wenn sich die Systemzeit von der Referenzzeit um mehr als ca. 1000 Sekunden unterscheidet. Da das in der Vergangenheit zu Problemen führte, wenn die initiale Systemzeit gänzlich falsch war, wurde oft vor dem Start des ntpd das Hilfsprogramm ntpdate ausgeführt, um die Systemzeit grob richtig zu setzen, bevor ntpd gestartet wurde, so dass die Grenze nicht überschritten werden konnte. Bereits vor einiger Zeit wurde der NTP-Daemon jedoch um einen Kommandozeilen-Parameter "-g" erweitert, der es erlaubt, dass die genannte Grenze nach dem Start einmalig überschritten werden darf, ohne dass ntpd sich beendet. Wenn dieser Parameter beim Start verwendet wird, ist der Aufruf von ntpdate daher überflüssig. Um die anfängliche Synchronisierung mit den externen NTP-Servern zu beschleunigen, kann weiterhin in der Datei /etc/ntp.conf die zu verwendenden Zeitserver mit dem Keyword "iburst" eingetragen werden, z.B.: server 0.pool.ntp.org iburst Wenn dieses Keyword verwendet wird, sendet ntpd zu Beginn mehrere Anfragen in kurzen Abständen an den Server, um den oben erwähnten Filter schneller aufzufüllen. Im Fall von openSUSE 10.3 wird standardmäßig noch ntpdate zur initialen Synchronisierung verwendet, wenn das Script rcntp aufgerufen wird, um den Dienst zu starten. Der erste Aufruf erfolgt dabei bereits, nachdem das Loopback-Interface initialisiert wurde, andere Netzwerk-Interfaces jedoch noch nicht. Da zu diesem Zeitpunkt keine Namensauflösung per DNS möglich ist, kann ntpdate nicht funktionieren. Später im Bootvorgang wird ntpd nochmals gestartet. Wie es aussieht, wird das rcntp-Script bei jedem "ifup" aufgerufen, um sicherzustellen, dass ntpd die Interfaces verwenden kann. Wieder wird zunächst ntpdate ausgeführt, anschließend ntpd gestartet. Dabei kann es passieren, dass eine frühere Instanz von ntpdate oder ntpd noch aktiv ist, so dass sich ntpd mit einer Fehlermeldung "another process may be running" beendet. Dadurch kann es passieren, das ntpd am Ende des Bottvorgangs nicht mehr läuft. Im Gegensatz zu früheren Versionen erkennt die aktuelle Version von ntpd jedoch auch Netzwerk-Interfaces, die nach seinem Start zur Verfügung gestellt werden. Dazu scannt ntpd zyklisch die vorhandenen Interfaces, man kann den Vorgang jedoch leider (noch) nicht durch ein externes Script auslösen. Um den Bootvorgang von openSUSE 10.3 (zumindest bei Verwendung von ifup) bezüglich ntpd zu verbessern, kann man nach meinen Erkenntnissen folgende Maßnahmen durchführen: 1.) Verhindern, dass ntpd bei jedem "ifup" neu gestartet wird 2.) Statt "ntpdate" aufzurufen, die Option "-g" verwenden 3.) Scan-Intervall für Interfaces auf kleinsten Wert ("-U 60") 4.) "iburst"-Keyword für server verwenden Für 1.) wird ein symbolischer Link in der Konfiguration für if-up gelöscht: rm /etc/sysconfig/network/if-up.d/50-ntp Für 2.) und 3.) wird die Datei /etc/sysconfig/ntp modifiziert und die angegebenen Einträge wie folgt geändert. NTPD_INITIAL_NTPDATE="" NTPD_OPTIONS="-g -U 60 -u ntp" Für 4.) wird in der Datei /etc/ntp.conf das Wort "iburst" an jede Server-Zeile gehängt, z.B.: server 0.pool.ntp.org iburst server 1.pool.ntp.org iburst server 2.pool.ntp.org iburst Ich würde mich freuen, wenn Ihr das auch testen könntet und mal schreibt, ob es für Euch ebenso funktioniert. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany -- 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

Hallo Jan, Am Samstag, 8. Dezember 2007 10:39:19 schrieb Jan Ritzerfeld:

Am Freitag, 7. Dezember 2007 schrieb Martin Burnicki:

...

Hallo miteinander,

Jan Ritzerfeld schrieb: [...] Oh. Das nenne ich mal ausführlich!

Hm, meine letzte Email war vom Inhalt her nicht speziell zu Deinem Problem. Beim Lesen der Threads, die sich mit NTP und allgemein mit der Zeit auf Computern beschäftigen, habe ich gesehen, dass allgemein ein paar Unklarheiten bestehen und dachte, ich versuche mal, die zu beseitigen.

...

Auf welche Weise das geschieht, hängt davon ab, welches Timer Tick-Intervall verwendet wird, welcher Timer des Mainboards verwendet wird, ob der Timer durch den Kernel vollständig und korrekt unterstützt wird, usw. Bei aktuellen Chipsätzen kann es damit Probleme geben, wenn z.B. aus Energiespargründen der Takt der CPU oder des Timers heruntergesetzt wird und das beim Anbringen der Korrektur nicht korrekt berücksichtigt wird.

Mit der Umstellung des Timers von acpi_pm auf irgendetwas anderes scheint der OP des Parallel-Threads zumindest teilweise Erfolg gehabt zu haben.

Ich habe leider kein System mit 10.3, auf dem ntpd es nicht schafft, die Zeit nachzuführen. Auf jeden Fall scheint der Lösungsansatz sinnvoll zu sein ...

...

(...). Wenn die dauerhafte Zeitsynchronisierung mit einer älteren Linux-Version problemlos funktioniert hat, mit der aktuellen Version auf der gleichen Hardware aber nicht, ist das ein Indiz für unzureichende Unterstützeung des verwendeten Timers durch den Kernel. Gerade um 2.6.21 herum wurde der Timer-Code im Kernel stark verändert. Hinweise auf sderartige Probleme sind Jan's zitierte Quellen (s.o.) oder auch entsprechende Meldungen in der NTP-Newsgroup, z.B.:

http://groups.google.de/groups?as_epq=opensuse+10.3&as_ugroup=comp.protocol s.time.ntp

Der Parallel-Thread beschreibt das Auftreten des Problems genau ab dem Zeitpunkt des Upgrades von 10.2 auf 10.3. Paßt ja ...

...

Zum Problem mit NTP beim Booten von openSUSE 10.3: Es handelt sich dabei um ein Problem mit den Init-Scripten. Siehe auch: https://bugzilla.novell.com/show_bug.cgi?id=337075

Auch wenn die Zusammenfassung es nicht vermuten läßt, dieser ältere Bug befaßt sich IMHO mit genau demselben Problem: https://bugzilla.novell.com/show_bug.cgi?id=256291

Stimmt. [...]

...

Um den Bootvorgang von openSUSE 10.3 (zumindest bei Verwendung von ifup) bezüglich ntpd zu verbessern, (...). Ich würde mich freuen, wenn Ihr das auch testen könntet und mal schreibt, ob es für Euch ebenso funktioniert.

Ich habe ein Notebook, daher nutze ich den NM. :-/

Ich werde in Kürze auch die Möglichkeit haben, mit einem Notebook zu testen. Mal sehen ...

Aber mein Problem beschränkt sich anscheinend eh nur auf die von dir erwähnte Race-Condition beim Booten. Wobei die Meldung etwas anders aussieht: "parent died before we finished, exiting" Jedenfalls läuft der ntp zumindest in 90 % der Fälle noch nach dem Boot, seitdem ich den NM-Timeout auf 10 hochgesetzt habe. Darüberhinaus habe ich wohl keinerlei Probleme mit der ständigen Synchronisation, allerdings läuft der Rechner auch nicht Tag und Nacht durch.

Ein Problem kann sich noch ergeben, wenn: - beim Hochlaufen des Notebooks eine große initiale Zeitabweichung besteht - ntpdate zunächst nicht erfolgreich aus geführt werden kann, weil z.B. das Netzwerk noch nicht vollständig läuft - ntpd ohne "-g" gestartet wird. Dann beendet sich ntpd aufgrund der zu großen Abweichung. M.E. sollten die in meiner letzten Mail angegebenen Hinweise auch bei Verwendung des NM nur vorteilhaft sein. Gruß, Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany -- 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

Hallo Christian, Christian Pubanz (GMX) schrieb:

Am Freitag, 7. Dezember 2007 17:28:19 schrieb Martin Burnicki:

...

Hallo miteinander, 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.

...

Um den Bootvorgang von openSUSE 10.3 (zumindest bei Verwendung von ifup) bezüglich ntpd zu verbessern, kann man nach meinen Erkenntnissen folgende Maßnahmen durchführen:

1.) Verhindern, dass ntpd bei jedem "ifup" neu gestartet wird 2.) Statt "ntpdate" aufzurufen, die Option "-g" verwenden 3.) Scan-Intervall für Interfaces auf kleinsten Wert ("-U 60") 4.) "iburst"-Keyword für server verwenden

Für 1.) wird ein symbolischer Link in der Konfiguration für if-up gelöscht:

rm /etc/sysconfig/network/if-up.d/50-ntp

Für 2.) und 3.) wird die Datei /etc/sysconfig/ntp modifiziert und die angegebenen Einträge wie folgt geändert.

NTPD_INITIAL_NTPDATE=""

NTPD_OPTIONS="-g -U 60 -u ntp"

Für 4.) wird in der Datei /etc/ntp.conf das Wort "iburst" an jede Server-Zeile gehängt, z.B.:

server 0.pool.ntp.org iburst server 1.pool.ntp.org iburst server 2.pool.ntp.org iburst

Ich würde mich freuen, wenn Ihr das auch testen könntet und mal schreibt, ob es für Euch ebenso funktioniert.

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. 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. 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. Viele Grüße, Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany -- 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

Christian Pubanz (GMX) schrieb:

Am Freitag, 21. Dezember 2007 13:08:05 schrieb Martin Burnicki: [...]

...

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.

Ich fürchte, das ist der Fall. Die Frage ist, ob das Grundproblem im Kernel oder an der Hardware liegt. Wenn z.B. der Timer-Takt aus Energiespargründen rauf und runtergeschaltet wird, aber der kernel bekommt die Umschaltung nicht korrekt mit, weil das (ACPI-) BIOS einen Fehler hat, dann hat ntpd kaum eine Chance, vernünftige Korrekturen anzubringen.

...

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.

Ja, "Bildschirm schwarz" kann während des Zeitsetzvorgangs passieren. Ich bin nicht 100% sicher, aber ich denke, es ist der Bildschirmschoner, der scheinbar eine längere Zeit der Untätigkeit erkennt.

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

Das sieht in der Tat schlimm aus. Leider erkennt man nicht, in welchem Zeitabstand die beiden Abfragen gemacht wurden. Das kann man aber aus der "loopstats"-Datei sehen. Siehe unten.

...

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?!

In der Datei /etc/ntp.conf, wie sie von openSUSE angelegt wird: Zeile: logfile /var/log/ntp # alternate log file Kommentar-Zeichen am Anfang einfügen: # logfile /var/log/ntp # alternate log file Nach dem nächsten Start des ntpd landen alle Meldungen des ntpd auch in /var/log/messages.

Und wie wird "loopstats" freigeschaltet?

In der gleichen Datei: # statsdir /tmp/ # directory for statistics files # filegen peerstats file peerstats type day enable # filegen loopstats file loopstats type day enable # filegen clockstats file clockstats type day enable ändern in: statsdir /tmp/ # directory for statistics files # filegen peerstats file peerstats type day enable filegen loopstats file loopstats type day enable # filegen clockstats file clockstats type day enable D.h., im Verzeichnis /tmp/ wird eine Datei "loopstats" angelegt, die täglich mit Datumsangabe umgespeichert wird, z.B.: loopstats.20071220 loopstats.20071221 usw. Der Inhalt sieht so aus: 54455 52542.007 0.000004846 35.417 0.000004976 0.020081 6 54455 52608.009 -0.000000544 35.417 0.000009995 0.018784 6 54455 52671.012 0.000002531 35.417 0.000008630 0.017571 6 Die Spalten bedeuten: 1. Datum als "Modified Julian Day", MJD 2. UTC-Zeit des Tages in Sekunden und Bruchteilen 3. Zeit-Offset (Sekunden) 4. Frequenz-Offset (Parts Per Million, PPM) 5. Mittlerer Jitter (Sekunden) 6. Allan Deviation (ein statistischer Wert in PPM) 7. Die Zeitkonstante der Regelschleife als Zweierpotenz Die Zeitkonstante "6" im Beispiel oben bedeutet, dass alle 2^^6 = 64 Sekunden eine Zeitnachregelung erfolgt. Interessant für uns ist, wie sich Zeit-Offset, Frequenz-Offset und Jitter im Dauerbetrieb verhalten. Nach dem "time reset" sollte der Zeitoffset erst klein sein. Es gibt ein paar Skripte, mit denen man das Ergebnis grafisch darstellen kann. Für einen Test solltest Du so vorgehen: # ntpd anhalten rcntp stop # Syslog-Messages löschen (oder Datei umbenennen, wenn Du # sie archivieren willst

/var/log/messages

# Drift-File löschen, falls es exitiert. # Wo die Datei liegt, kannst Du in ntp.conf sehen, z.B.: # driftfile /var/lib/ntp/drift/ntp.drift # path for drift file rm /var/lib/ntp/drift/ntp.drift # Loopstats löschen rm /tmp/loopstats Dann neu Booten und den Rechner ein paar Stunden laufen lassen. Zwischendurch kannst Du kontrollieren, ob eine Datei /tmp/loopstats angelegt wird, und was drinsteht. Auch ein "ntpq -p" zwischendurch kann nicht schaden. Eine schöne Beschäftigung über Weihnachten ;-)) Viele Grüße, Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany -- 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

Hallo Christian, zunächst wünsche ich Dir und allen hier ein frohes und gesundes neues Jahr! Christian Pubanz (GMX) schrieb:

Am Freitag, 21. Dezember 2007 16:09:12 schrieb Martin Burnicki: Hallo Martin,

hoffe, du hattest ein schönes Weihnachtsfest!

Ja, danke. Ich hoffe, Du auch. [...]

...

...

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. Ich fürchte, das ist der Fall. Die Frage ist, ob das Grundproblem im Kernel oder an der Hardware liegt. Wenn z.B. der Timer-Takt aus Energiespargründen rauf und runtergeschaltet wird, aber der kernel bekommt die Umschaltung nicht korrekt mit, weil das (ACPI-) BIOS einen Fehler hat, dann hat ntpd kaum eine Chance, vernünftige Korrekturen anzubringen.

Hmm...

Habe heute morgen einen Beitrag im User-Forum von Fujitsu-Siemens verfasst, die Problematik dargestellt und gefragt, ob jemand mir nähere technische Infos zu dem in meinem Mainboard verarbeiteten Timer-Quarz geben kann.

(siehe http://support.fujitsu-siemens.de/forum/viewtopic.php?t=27483)

Leider ist ja aus dem technischen Handbuch das ja nicht so ersichtlich!

"Der Quarz" an sich wird nicht das Problem sein, sondern eher der Chipsatz, dessen Taktfrequenz heruntergeschaltet wird, um Energie zu sparen und dadurch die Akku-Laufzeit zu erhöhen. Stell Dir vor, der Timer läuft normalerweise mit 1000 Takten pro Sekunde, d.h. nach jeweils 1000 Takten muß die Software-Uhr des Kernels 1 Sekunde hinzuaddieren. Wenn jetzt die Timer-Taktrate auf 800 Takte/s heruntergesetzt wird, um Energie zu sparen, muß der Kernel das mitbekommen, damit er weiß, dass bereits nach 800 Takten eine neue Sekunde beginnt. Wenn der Linux-Kernel die Umschaltungen nicht korrekt mitbekommt, zählt er die Sekunde weiterhin erst nach 1000 Takten weiter, d.h. die Software-Uhr geht viel zu langsam. Die Werte oben sind natürlich nur ein Beispiel, um das Problem zu verdeutlichern. Der Grund, warum der Kernel das nicht mitbekommt, kann entweder im Kernel liegen, wenn der Chipsatz des Laptop nich vollständig bzw. korrekt unterstützt wird. Andererseits kann auch eine fehlerhafte bzw. unvollständige Implementierung des (ACPI-) BIOS des Rechners schuld sein. Vielleicht zeigt Du mal die Ausgabe von: # grep -i "clock\|tsc\|acpi_pm" /var/log/boot.msg Daraus sollte ersichtlich sein, welchen Timer der Kernel für die Systemzeit verwendet. (siehe https://bugzilla.novell.com/show_bug.cgi?id=350981) Du könntest auch mal sehen, ob die Systemzeit auch wegläuft, wenn ntpd nicht läuft. Also zunächst ntpd anhalten und die Systemzeit mit ntpdate hart setzen: rcntp stop date -u; ntpdate ptbtime1.ptb.de Dann den laptop einige Stunden laufen lassen und mit ntpdate prüfen, wie weit die Systemzeit weggedriftet ist. Wichtig ist hier der zusätzliche Parameter "-q" für "query only", damit nur die Zeitdifferenz angezeigt wird, ohne die Systemzeit zu setzen: date -u; ntpdate -q ptbtime1.ptb.de Das "date -u" gibt vorher noch die aktuelle Systemzeit aus, dann kann man in der Historie der Konsolenmeldungen sehen, wieviel Zeit zwischen den Aufrufen vergangen i st. Bei mir sieht die Ausgabe z.B. so aus: # date -u; ntpdate -q ptbtime1.ptb.de Mi Jan 2 09:26:09 UTC 2008 server 192.53.103.108, stratum 1, offset 0.000919, delay 0.04536 2 Jan 10:26:09 ntpdate[29113]: adjust time server 192.53.103.108 offset 0.000919 sec # date -u; ntpdate -q ptbtime1.ptb.de Mi Jan 2 09:28:37 UTC 2008 server 192.53.103.108, stratum 1, offset 0.000067, delay 0.04355 2 Jan 10:28:37 ntpdate[29168]: adjust time server 192.53.103.108 offset 0.000067 sec Natürlich ist eine wiederholte Anfrage in so kurzem Zeitabstand wie oben nicht besonders aussagekräftig. Besser wäre die Ausgabe nach 1 Stunde, nach 2 Stunden, ... [...]

...

Dann neu Booten und den Rechner ein paar Stunden laufen lassen. Zwischendurch kannst Du kontrollieren, ob eine Datei /tmp/loopstats angelegt wird, und was drinsteht. Auch ein "ntpq -p" zwischendurch kann nicht schaden.

Hab ich gemacht-läuft nicht! :-(

Anbei findet sich meine NTP.conf-habe die entsprechenden Zeilen genau so ersetzt, wie du beschrieben hast...

Schaue ständig ins /tmp-Verzeichnis-bisher ist leider noch keine loopstats-Datei aufgetaucht;auch keine versteckte... :-(

Schau mal in Deine /var/log/messages. Da steht zyklisch: ntpd[3359]: can't open /tmp/loopstats.20071227: Permission denied Das sieht so aus, als ob Apparmor das Erstellen der Datei verhindert. Entweder muß das Apparmor-Profil für ntpd so geändert werden, dass ntpd in /tmp/ schreiben darf, oder Du kannst Apparmor einfach deaktivieren: Temporär über "rcapparmor stop" oder dauerhaft über yast2->NovellApparmor->Apparmor-Kontrolleiste->Checkbox "Enable Apparmor" deaktivieren. Bitte kommentiere auch (wenigstenst zunächst) noch alle "restrict"-Zeilen in Deiner ntp.conf aus, bevor Du weitere Versuche mit ntpd startest ... Viele Grüße, Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany -- 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

Hallo Christian, Christian Pubanz (GMX) schrieb:

Am Mittwoch, 2. Januar 2008 11:28:32 schrieb Martin Burnicki:

...

Hallo Christian, Hallo Martin, zunächst wünsche ich Dir und allen hier ein frohes und gesundes neues Jahr! vielen Dank, dir und allen anderen auch (noch). Kam (mal wieder) erst jetzt zum Ausprobieren. Bitte meine Langsamkeit vielmals zu entschuldigen...

Kein Problem, bei meinem Rechner funktionierts ja ;-)) [...]

...

Vielleicht zeigt Du mal die Ausgabe von: # grep -i "clock\|tsc\|acpi_pm" /var/log/boot.msg Büdde:

<6>Time: tsc clocksource has been installed. <6>Real Time Clock Driver v1.12ac <6>intel8x0_measure_ac97_clock: measured 53708 usecs <6>intel8x0: clocking to 49937 doneSetting up the hardware clock<notice>killproc: kill(1082,29)

Also wird der TSC-Timer auf deinem Rechner für die Systemzeit verwendet. [...]

...

Also zunächst ntpd anhalten und die Systemzeit mit ntpdate hart setzen:

rcntp stop date -u; ntpdate ptbtime1.ptb.de

Dann den laptop einige Stunden laufen lassen und mit ntpdate prüfen, wie weit die Systemzeit weggedriftet ist. Wichtig ist hier der zusätzliche Parameter "-q" für "query only", damit nur die Zeitdifferenz angezeigt wird, ohne die Systemzeit zu setzen:

date -u; ntpdate -q ptbtime1.ptb.de

Das "date -u" gibt vorher noch die aktuelle Systemzeit aus, dann kann man in der Historie der Konsolenmeldungen sehen, wieviel Zeit zwischen den Aufrufen vergangen i st. Hab ich gemacht, anbei eine TXT-Datei mit zwei Ergebnissen. Dummerweise habe ich bei dem einen Test vergessen, dass -q zu verwenden, so dass die Systemzeit anschließend korrigiert wurde. Aber bei dem zweiten Ergebnis kann man ganz eindrucksvoll sehen, dass, auch wenn der NTPD nicht läuft, die Zeit "wegläuft"...

Yep, 300 Sekunden n 2 Stunden ist schon heftig. Da kommt der NTP-Daemon nicht mehr hinterher. Deshalb hat er wohl auch meist nichtssagende Werte (0.00..) in die loopstats geschrieben ... Wenn Dir die Lust noch nicht vergangen ist, könntest Du noch folgendes ausprobieren. Zunächst anzeigen lassen, welche Timer-Module auf Deinem System unterstützt werden: # cat /sys/devices/system/clocksource/clocksource0/available_clocksource hpet acpi_pm pit jiffies tsc Hier im Beispiel sind es hpet, acpi_pm, pit, jiffies und tsc. Dann nochmal sehen, welches Modul aktuell verwendet wird: # cat /sys/devices/system/clocksource/clocksource0/current_clocksource Bei Dir wird dann wahrscheinlich ausgegeben: tsc Um herauszufinden, ob eines der anderen aufgelisteten Module auf Deinem System die Systemzeit besser hält, könntest Du jeweils eins der Module als Bootparameter konfigurieren, indem Du einfach beim Bootprompt des Grub das gewünschte Modul eingibst, z.B.: clocksource=jiffies Danach den Test mit "ntpdate -q" wiederholen, wie gehabt _ohne_ ntpd. Falls eins der Timer-Module besser funktioniert als tsc, könntest Du das entsprechende Modul fest als Vorgabe eintragen. Gruß, Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany -- 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

Hallo Christian, sorry, diesmal hat's bei mir lange mit der Antwort gedauert. Christian Pubanz (GMX) schrieb:

Am Mittwoch, 16. Januar 2008 18:04:23 schrieb Martin Burnicki: [...]

...

Um herauszufinden, ob eines der anderen aufgelisteten Module auf Deinem System die Systemzeit besser hält, könntest Du jeweils eins der Module als Bootparameter konfigurieren, indem Du einfach beim Bootprompt des Grub das gewünschte Modul eingibst, z.B.:

clocksource=jiffies

Danach den Test mit "ntpdate -q" wiederholen, wie gehabt _ohne_ ntpd. Falls eins der Timer-Module besser funktioniert als tsc, könntest Du das entsprechende Modul fest als Vorgabe eintragen.

Hab ich gemacht, aber alle verfügbaren Module verhalten sich gleich. Die Zeit weicht überall ab-egal was ich beim Bootprompt einsetze.

Hm, das sieht nicht gut aus. Theoretisch könntest Du noch versuchen, mit dem Programm adjtimex den Standard-Tickwert bzw. die Frequenz anzupassen. Ich habe das aber selbst auch noch nicht gemacht und weiß deshalb momentan auch nicht, wie man am besten vorgeht, ob bzw. wie die geänderten Werte dauerhaft gespeichert werden, und ob das überhaupt noch mit dem neuen Clock-Modell der Kernels 2.6.2x richtig funktioniert.

Kann ich irgendwo vielleicht noch Module runterladen und austesten?

Nicht, dass ich wüßte.

Oder was für Möglichkeiten habe ich noch-wenn's überhaupt noch welche gibt...;-)

Mir fällt nur adjtimex ein. Ich werde mal sehen, ob ich dazu mehr herausfinde. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany -- 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

Am Dienstag, 4. Dezember 2007 16:32:00 schrieb Ralf Arndt:

Hi Christian, Hi Ralf!

Sorry für die Verspätung, aber ich hatte ein Projekt am Laufen, für dass ich nun einigermaßen vorgearbeitet habe. Jetzt kann ich mich wieder dem Problem mit dem NTPD zuwenden. :-)

...

Richtig! Ich wäre ja überhaupt froh, wenn der NTPD arbeiten würde, was er aber nicht tut!

Um ein Missverständnis klarzustellen: Mit dem ntpd stellst Du selber einen ntp Server in Deinem Netz bereit. Das brauchst Du vermutlich nicht. Gut zu wissen! ;-)

Der ntpd hängt nur indirekt mit Deinem ntp Client zusammen: Ich nehme mal an Du hast ntp über yast konfiguriert und dabei den Haken bei "ntp daemon beim booten starten" gesetzt. In dem Fall trägt yast die von Dir eingetragenen ntp Server unter NTPD_INITIAL_NTPDATE in der Datei /etc/sysconfig/ntp ein Hmm... Seltsam! Ich hab gerade die /etc/sysconfig/ntp offen, aber unter NTPD_INITIAL_NTPDATE steht als Wert ""-nix!

Yast hat meine Server also nicht in die Datei eingetragen! Soll ich das mal manuell machen?

.

Ergebnis: ntpd beendet sich wieder, wenn es nicht gelingt von den ntp Servern eine gültige Zeit zu erhalten. Deshalb der indirekte Zusammenhang. Logisch! Wo auch kein Wert vorgegeben ist, kann auch nichts abgeglichen werden!

...

...

...

...

Gehe bitte mal beim booten in das BIOS Setup und schau nach, ob die Uhr richtig geht.

Damit kann ich momentan leider nicht dienen; bei mir spinnt derzeit mein Monitor/Grafikkarte-jedenfalls komme ich derzeit nicht ins BIOS! Klingt komisch-ist aber so! :-D

Schade

Inzwischen komm ich wieder ins BIOS (hab den Bildschirm ausgetauscht) und konnte da feststellen, dass die Uhr ca. 6 Minuten vorgeht-hab sie dort gleich richtig gestellt. BIOS-Batterie hab ich übrigens vor nem guten Jahr erneuert-an der kann's also auch nicht liegen...

Jetzt wäre interessant zu erfahren, ob Deine BIOS Uhr so eine Abweichung hat, oder ob die falsche Zeit von einem OS gesetzt wird.

Kannst Du mal - wenn Du den Rechner länger nicht benutzt - im BIOS prüfen, ob sich die Uhr verstellt hat (ohne zwischendurch ein OS zu starten)? Puh! Das ist schwierig! Ich brauche meinen Rechner täglich und habe ihn, unterbrochen von kleinen Pausen für Essen, Gänge in die Stadt etc. nur Nachts "richtig" aus (also 6-8 Stunden am Stück-inkluvsive Trennung vom Stromnetz) Würde das genügen?

...

...

...

...

Was sagt denn ein ntpdate ntp1.ptb.de

25 Nov 23:15:23 ntpdate[4810]: step time server 192.53.103.108 offset -363.490977 sec

Rund 6 Minuten Abweichung. Weis hier jemand ab welcher Abweichung der Server ignoriert wird? Ich finde das nicht auf die Schnelle. Ich hab mal gelesen ab 5 min... Aber selbst weiß ich das auch nicht 100%ig!

...

...

...

...

Das hatte ich (glaube ich) schonmal gefragt: Hast Du ein Dualboot System mit Windows.

Nein, das hattest du bisher noch nicht gefragt. Ich habe Linux/Windows zur Auswahl (Windows für Video/Sound-Anwendungen)-falls das mit "Dual-Boot" gemeint war. Davor startet GRUB zur Systemauswahl.

Genau das habe ich gemeint. Es gibt haufenweise Threads auf der Liste zu Problemen mit Zeit und Dual Boot Systemen (Windows + Linux). Such mal danach.

Das Problem tritt allgemein auf, wenn 2 Systeme meinen die RTC umstellen zu müssen, verstärkt im Zusammenhang mit der Umstellung Sommer- und Winterzeit.

...

Kannst du mir vielleicht ein paar Beispiellinks geben ?

Google Sucheargument: "zeitumstellung site:opensuse.org" OK, mach ich gleich!

Schicke bitte mal die Ausgaben von cat /etc/adjtime 2.235111 1197195991 0.000000 1197195991 LOCAL cat /var/lib/ntp/drift/ntp.drift 0.000 cat /var/lib/ntp/var/lib/ntp/drift/ntp.drift 0.000 (die letzte Datei existiert vermutlich nur wenn ntp in einer chroot Umgebung läuft.) Weiß nicht, was das genau ist, aber scheinbar existiert diese Datei!

Benenne die Dateien mal um und starte Linux neu (kein Windows dazwischen booten). Tritt der Fehler dann immer noch auf? Dumme Frage, aber nach was umbennen? Irgendeinen beliebigen Namen (schlagmichtot.drift) oder muss das ein spezieller, neuer Name sein?

Wie ist Windows konfiguriert? Windows benutze ich eigentlich nur noch zur Video/Sound-Bearbeitung, also keine große spezial-Konfiguration. Windows XP Professional hab ich; da sind alle wichtigen Geräte (USB-Tastatur/PS2-Maus, LPT1 Drucker) und-vielleicht erwähnenswert in diesem Zusammenhang: Firewire-Anschluss an die Digitalkamera. Ansonsten nichts "weltbewegendes"... ntp Client? Nein, unter Windows nicht! Automatisch umstellen zwischen Sommer/Winterzeit? Ja!

Ich hänge mal noch die /etc/sysconfig/ntp dran, mich wundert das mit dem fehlenden Wert bei NTPD_INITIAL_NTPDATE. Vielleicht liegt da der "Hase im Pfeffer"! @Jan Ritzerfeld&Martin Burnicki: Danke auch für eure Mails-schau mir eure Tips/Hinweise bei Gelegenheit näher an und antworte darauf seperat! Vielen Dank und einen schönen 2. Advent! Grüße, Christian