From owner-freebsd-stable@FreeBSD.ORG Fri Apr 1 20:17:06 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BFB8216A4CE for ; Fri, 1 Apr 2005 20:17:06 +0000 (GMT) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id D81F243D48 for ; Fri, 1 Apr 2005 20:17:05 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j31KH3tr006887 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 2 Apr 2005 06:17:04 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j31KH37l080840; Sat, 2 Apr 2005 06:17:03 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j31KH2Pi080839; Sat, 2 Apr 2005 06:17:02 +1000 (EST) (envelope-from pjeremy) Date: Sat, 2 Apr 2005 06:17:02 +1000 From: Peter Jeremy To: Andriy Gapon Message-ID: <20050401201701.GK71384@cirb503493.alcatel.com.au> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <424D7911.8060805@icyb.net.ua> User-Agent: Mutt/1.4.2i cc: stable@freebsd.org Subject: Re: Kernel NTP flipping between FLL and PLL modes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2005 20:17:06 -0000 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