Re: Linux 2.6.29-rc6

From: Jesper Krogh
Date: Tue Mar 03 2009 - 15:19:59 EST


john stultz wrote:
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:
john stultz wrote:
Ok, so it seems ntp hasn't really had a chance to settle down, its only
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.
After 20 hours.. its still resetting.
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
So what's the "ntpdc -c kerninfo" output now?
Mar 3 06:41:10 quad12 ntpd[4416]: time reset -0.813957 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.

It's resetting.. without deep knowledge about ntp, doesnt that mean "start over again"? I believe it hits +/-500ppm

Could you provide:
/usr/sbin/ntpdc -c version

$ ntpdc -c version
ntpdc 4.2.4p4@xxxxxxxx Tue Jan 6 15:51:00 UTC 2009 (1)

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.

Will try those option while debugging.

Actually, if you could, I'd be interested if you could send your
ntp.conf

http://krogh.cc/~jesper/ntp.conf

But this seems to be a "regression". Since 2.6.27.19 doesn't misbehave. Same NTP, same configuration, same hardware. only change is the kernel version. Or am I missing some parameter here?

Would it make sense to try to bisect it?

Jesper

--
Jesper
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/