On Tue, 2009-03-03 at 07:04 +0100, Jesper Krogh wrote:john stultz wrote:On Mon, 2009-03-02 at 10:53 +0100, Jesper Krogh wrote:Mar 3 06:41:10 quad12 ntpd[4416]: time reset -0.813957 sjohn stultz wrote:So what's the "ntpdc -c kerninfo" output now?Ok, so it seems ntp hasn't really had a chance to settle down, its onlyAfter 20 hours.. its still resetting.
made a 10ppm adjustment so far. NTPd will stop corrections at ~
+/-500ppm, so you're not at that bound yet, where things would be really
broken.
If the affected kernel isn't resetting in the logs anymore, I'd be
interested in what the new ppm value is.
Mar 2 10:43:24 quad12 ntpd[4416]: synchronized to 10.194.133.12, stratum 4
Mar 2 10:50:37 quad12 ntpd[4416]: time reset -1.103654 s
Mar 3 06:45:20 quad12 ntpd[4416]: synchronized to LOCAL(0), stratum 13
Mar 3 06:45:36 quad12 ntpd[4416]: synchronized to 10.194.133.12, stratum 4
Mar 3 06:51:57 quad12 ntpd[4416]: synchronized to 10.194.133.13, stratum 4
Mar 3 07:00:29 quad12 ntpd[4416]: time reset -0.783390 s
jk@quad12:~$ ntpdc -c kerninfo
pll offset: 0 s
pll frequency: -28.691 ppm
This is baffling. You've only gone from -34.754ppm to -28.691ppm in over
a day? And you're still not syncing? If the calibration was so bad that
NTP couldn't sync, I'd expect the freq value to hit +/-500ppm before it
gave up. This just doesn't follow my expectations.
Could you provide:
/usr/sbin/ntpdc -c version
Do you see the same behavior if you drop all but one server (including
the local clock: 127.127.1.0)?
You might also add "minpoll 4 maxpoll 4" to the server line to speed up
testing.
Actually, if you could, I'd be interested if you could send your
ntp.conf