From owner-freebsd-stable@FreeBSD.ORG Wed Apr 6 08:16:09 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 12F6116A4CE for ; Wed, 6 Apr 2005 08:16:09 +0000 (GMT) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F4D743D41 for ; Wed, 6 Apr 2005 08:16:07 +0000 (GMT) (envelope-from avg@icyb.net.ua) Received: from [212.40.38.87] (oddity-e.topspin.kiev.ua [212.40.38.87]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA28022; Wed, 06 Apr 2005 11:13:49 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <42539A3C.7070807@icyb.net.ua> Date: Wed, 06 Apr 2005 11:13:48 +0300 From: Andriy Gapon User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050328) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Jeremy 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> In-Reply-To: <20050405193226.GB84293@cirb503493.alcatel.com.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit cc: David Magda 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: Wed, 06 Apr 2005 08:16:09 -0000 on 05.04.2005 22:32 Peter Jeremy said the following: > Note that this code doesn't exist in 5.3. It was introduced sometime > between 5.3 and 5.4. In any case, looking at the associated comments, > this only affects the FLL/PLL loop gain. Yes, I see that I looked in a wrong place. > The FLL/PLL switch is set is in sys/kern/kern_ntptime.c:hardupdate() > using: > time_status &= ~STA_MODE; > if (mtemp >= MINSEC && (time_status & STA_FLL || mtemp > MAXSEC)) { > L_LINT(ftemp, (time_monitor << 4) / mtemp); > L_RSHIFT(ftemp, SHIFT_FLL + 4); > L_ADD(time_freq, ftemp); > time_status |= STA_MODE; > } > and this code hasn't changed. MINSEC is 256 (which matches the comments) > MAXSEC is either 1200 or 2048 (depending on which header file is active), > though the comments imply it is 1024. mtime is the time since the last > adjustment (call to hardupdate()). MAXSEC==2048 is used, the contrib header file could not be included because its directory is not included with -I. Besides I've verified it by sneaking in -E > STA_FLL is set in ntpd/ntp_loopfilter.c: > if (sys_poll > NTP_MAXDPOLL) > ntv.status |= STA_FLL; > though the associated comment states "for legacy only". (And I'm > never seeing STA_FLL transitions in syslog). This sets STA_FLL if the > polling interval is > 2^10 (1024). By default, sys_poll is limited to > NTP_MAXDPOLL so this should never occur. (You can over-ride it with > "maxpoll N" on peer/server config lines). 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. BTW, what is the best way to get out of ntpd everything it can tell about its operations ? -- Andriy Gapon