-----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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
