Date: Wed, 06 Apr 2005 13:45:47 +0300 From: Andriy Gapon <avg@icyb.net.ua> To: Andriy Gapon <avg@icyb.net.ua> Cc: stable@freebsd.org Subject: Re: Kernel NTP flipping between FLL and PLL modes Message-ID: <4253BDDB.3060805@icyb.net.ua> In-Reply-To: <42539A3C.7070807@icyb.net.ua> References: <1112365401.00269464.1112352602@10.7.7.3> <1112372627.00269546.1112361001@10.7.7.3> <1112372655.00269555.1112362202@10.7.7.3> <424D7911.8060805@icyb.net.ua> <6.2.0.14.2.20050401183743.04813c10@gid.co.uk> <42527E03.5090805@icyb.net.ua> <20050405193226.GB84293@cirb503493.alcatel.com.au> <42539A3C.7070807@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
on 06.04.2005 11:13 Andriy Gapon said the following: > I am using the default value of maxpoll, no overrides. > So, IMO this leaves one possibility: mtemp > 2048, i.e. hardupdate() was > not called for longer than this time i.e. either ntp_adjtime() was not > called or it was called without MOD_OFFSET. > It looks like it is not trivial to find the cause of this. > I can not explain it, but I've suddenly got a gut feeling that the subject discussed might be a result of revision 1.53 of sys/kern/kern_ntptime.c Deal with MOD_FREQUENCY before MOD_OFFSET because the latter is the one which runs the actual update. This fixes a bug where there were a delay in applying the frequency adjustment. In extreme cases this could result in marginal stability of the kernel-pll. I can test this hypothesis as soon as I get a chance to reboot the machine in question (might not be soon). -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4253BDDB.3060805>