Date: Sat, 2 Apr 2005 06:17:02 +1000 From: Peter Jeremy <PeterJeremy@optushome.com.au> To: Andriy Gapon <avg@icyb.net.ua> Cc: stable@freebsd.org Subject: Re: Kernel NTP flipping between FLL and PLL modes Message-ID: <20050401201701.GK71384@cirb503493.alcatel.com.au> In-Reply-To: <424D7911.8060805@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2005-Apr-01 19:38:41 +0300, Andriy Gapon wrote: >I can second that. I have never seen anything like this with 5.2.1 as >soon as I upgraded to 5.3 I started seeing messages like these: ... >Mar 29 22:15:40 oddity ntpd[400]: time reset -0.288522 s >Mar 29 22:15:40 oddity ntpd[400]: kernel time sync enabled 6001 >Mar 29 23:09:19 oddity ntpd[400]: time reset +0.530732 s >Mar 29 23:09:19 oddity ntpd[400]: kernel time sync enabled 2001 >Mar 29 23:35:18 oddity ntpd[400]: time reset -0.165853 s >Mar 30 00:41:14 oddity ntpd[400]: time reset -0.199104 s >Mar 30 11:21:21 oddity ntpd[400]: kernel time sync enabled 6001 >Mar 30 11:38:27 oddity ntpd[400]: kernel time sync enabled 2001 >Mar 30 17:22:37 oddity ntpd[400]: time reset -0.392425 s >Mar 30 17:22:37 oddity ntpd[400]: kernel time sync enabled 6001 >Mar 30 17:26:06 oddity ntpd[400]: kernel time sync enabled 2001 >Mar 30 17:28:15 oddity ntpd[400]: time reset +0.309711 s >Mar 30 18:07:02 oddity ntpd[400]: time reset +0.164515 s >Mar 30 18:41:43 oddity ntpd[400]: time reset -0.391355 s >Mar 30 19:00:17 oddity ntpd[400]: time reset +0.598313 s >Mar 30 19:47:45 oddity ntpd[400]: time reset -0.276978 s >Mar 30 21:26:24 oddity ntpd[400]: time reset +0.158781 s >Mar 30 23:18:01 oddity ntpd[400]: time reset +0.160708 s ... >2001<->6001 flips do not trouble me a bit (but annoying), time resets >are not a good thing definitely. I've seen similar reset behaviour in the past. The investigating I did suggested that the PLL could become unstable under some conditions (though I never managed to work out exactly what triggered the mis-behaviour). It would either lock up around +/- 500ppm and regularly jump in one direction to compensate or it would start swinging wildly and regularly jump back and forth with the net time jumped close to zero (in the latter case, looking at the loopstats showed that the frequency offset would start oscillating with the swings getting larger over time). Manually setting ntp.drift to a realistic value and restarting ntpd seemed to cure the problem (at least temporarily). I haven't seen that problem recently - I think it was in the early 4.x period. >I suppose that it might be possible that the root cause is in my local >network conditions, If it is network conditions, enabling huff-puff might help. If possible, work out what the real drift on that system is and re-initialise ntp.drift as well. -- Peter Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050401201701.GK71384>