-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-12-07 at 03:31 -0500, Aaron Kulkis wrote:
In your first post, one of your own logfile excerpts shows a line where it is syncing to a strata 10 source. Every line after that shows attempts to re-sync to a strata 2 source, with very large corrections, and if I remember correctly, fails to do so.
Perhaps you should comment out your strata 10 source.
That's the local system clock: 27 Nov 15:39:40 ntpd[12905]: synchronized to LOCAL(0), stratum 10 And I have disabled the local source on the config, no effect: server 127.127.1.0 # local clock (LCL) fudge 127.127.1.0 stratum 10 # LCL is unsynchronized
+ 27 Nov 15:31:56 ntpd[12905]: synchronized to 91.121...., stratum 2 + 27 Nov 15:38:31 ntpd[12905]: synchronized to 192.33...., stratum 2 + 27 Nov 15:39:25 ntpd[12905]: synchronized to 195.55...., stratum 2 + 27 Nov 15:39:40 ntpd[12905]: synchronized to LOCAL(0), stratum 10 + 27 Nov 16:22:22 ntpd[12905]: synchronized to 84.88...., stratum 2 + 27 Nov 16:22:22 ntpd[12905]: time correction of 1678 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time.
When the network peers are lost, it connects to the local clock. When it gets again a network peer, it discovers the error. After I disabled the local clock, it appears to find a peer faster; but that's early to say, because the "sanity" error /only/ happened 5 times in a month. Now I get the reset oftener.
It should be able to keep accurate time for hours, even days. This was so with previous suse versions, but not with 10.3. It drifts minutes in half an hour. This is unthinkable!
Because after it loses its strata 3 network source, it reverts to the strata 10 source (CMOS clock on the motherboard), and that's when your problems begin.
No, that's not the cmos clock. That's the system clock. The cmos clock is correct to the second: nimrodel:~ # cat /sys/devices/system/clocksource/clocksource0/current_clocksource ; cat /var/lib/ntp/drift/ntp.drift ; hwclock --show ; date tsc - -11.841 Fri Dec 7 13:25:20 2007 -0.520012 seconds Fri Dec 7 13:25:20 CET 2007 If the ntp where really using the cmos clock as a source there would be no problem: it is a faithful clock. But that can not be used as a source because querying the cmos clock is an "expensive" task. It is a read of two i/o ports and very slow: you try, try "hwclock --show ; date" and you will see that it takes about a second to respond - actually, the number with decimals is related to that time: nimrodel:~ # time ( hwclock --show ; date ) Fri Dec 7 13:33:19 2007 -0.975686 seconds Fri Dec 7 13:33:19 CET 2007 real 0m0.982s user 0m0.004s sys 0m0.000s nimrodel:~ # time ( hwclock --show ; date ) Fri Dec 7 13:33:27 2007 -0.944349 seconds Fri Dec 7 13:33:27 CET 2007 real 0m0.951s user 0m0.000s sys 0m0.004s nimrodel:~ # time ( hwclock --show ; date ) Fri Dec 7 13:33:33 2007 -0.437496 seconds Fri Dec 7 13:33:33 CET 2007 real 0m0.444s user 0m0.000s sys 0m0.008s - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHWT4LtTMYHG2NR9URAtktAJ9lmm/XrRAXy1CB5bVkGRx/sbNpMACfe9/C ohN/oyVkW7Bcx5Ytyl24tAQ= =YaF2 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org