From owner-freebsd-stable@FreeBSD.ORG Tue Dec 19 19:55:38 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2FB2816A40F; Tue, 19 Dec 2006 19:55:38 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D401243CEB; Tue, 19 Dec 2006 19:55:07 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.13.7/8.13.7) with ESMTP id kBJJi3dO059799; Tue, 19 Dec 2006 11:44:06 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.13.7/8.13.4/Submit) id kBJJhrVM059792; Tue, 19 Dec 2006 11:43:53 -0800 (PST) Date: Tue, 19 Dec 2006 11:43:53 -0800 (PST) From: Matthew Dillon Message-Id: <200612191943.kBJJhrVM059792@apollo.backplane.com> To: Jeremy Chadwick References: <20061219124151.GA33385@icarus.home.lan> <20061219132032.GA66632@slackbox.xs4all.nl> <45880BA6.80907@jellydonut.org> <20061219165741.GA40101@icarus.home.lan> Cc: Michael Proto , freebsd-stable@freebsd.org Subject: Re: ntpd flipping between PLL and FLL mode X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2006 19:55:38 -0000 :How would decreasing the polling time fix this? I do not understand :the semantics/behaviour of NTP very well. : :Taken from the manpage: : : maxpoll maxpoll : These options specify the minimum and maximum poll intervals for : NTP messages, in seconds to the power of two. The maximum poll : interval defaults to 10 (1,024 s), but can be increased by the : maxpoll option to an upper limit of 17 (36.4 h). The minimum : poll interval defaults to 6 (64 s), but can be decreased by the : minpoll option to a lower limit of 4 (16 s). Though I can't speak to the algorithm ntpd uses, if a correllation is used along with a standard deviation to calculate offset and frequency errors, then decreasing the polling interval makes it virtually impossible to get an accurate frequency lock. Frequency locks require long polling intervals. So you wouldn't see any flips (or fewer flips), but you wouldn't have a very accurate time base either. You know you have a bad frequency correction if you see significant offset corrections occuring every day. The whole concept of 'flips' is broken anyhow, it just means the application is not using the correct mathmatical algorithm. NTPD never worked very well for me in all the years I've used it. Not ever. OpenNTPD also uses an aweful algorithm. If you need a NTP client-only app you might want to consider porting our DNTPD. It is a client-only app (no server component) which uses two staggered correllations and two staggered standard deviations for each time source and corrects the time based on a mathmatically calculated accuracy rather then after some pre-contrived time delay or interval. Some minor messing around might be needed to port it since we use a slightly more advanced sysctl scheme to control offset and frequency correction. It also has a tendancy to make errors in OS time keeping obvious. In particular, any bugs in how the OS handles offset and frequency corrections will become very obvious. We found a microsecond-vs-nanosecond bug in DragonFly with it. If you have a good frequency lock you should not see offset corrections occuring very often. I've included examples of what you should be able to achieve below from a few of our machines. In the examples below I got a reasonable frequency lock within an hour and then did not have to correct for it after that (which means that the error calculation for the continuously running frequency drift calculation was not small enough to make further frequency corrections). These are using the pool NTP sources on the internet. With a LAN source you would probably see more frequency corrections. Correllations are only useful with a limited number of samples... once you get beyond 30 samples or so the algorithm tends to plateau, which is why you need to have at least two running correllations with staggered start times. I have considered adding two additional staggered correllations to get more accurate frequency locks (e.g. 30 2 hour samples in addition to 30 30 minute samples) but PC time bases just aren't accurate enough to justify it (I know of no PC motherboards which use temperature-corrected crystal time bases. They are all uncorrected time bases. It's really annoying). Ah well. -Matt Dec 3 10:46:57 crater dntpd[605]: dntpd version 1.0 started Dec 3 10:47:13 crater dntpd[605]: issuing offset adjustment: 0.706663 Dec 3 11:29:32 crater dntpd[605]: issuing offset adjustment: 0.015905 Dec 3 11:39:57 crater dntpd[605]: issuing frequency adjustment: 8.656ppm Dec 3 11:50:25 crater dntpd[605]: issuing offset adjustment: 0.011579 Dec 4 09:21:18 crater dntpd[605]: issuing offset adjustment: -0.007325 Dec 5 20:26:08 crater dntpd[605]: issuing offset adjustment: 0.007002 Dec 6 09:20:32 crater dntpd[605]: issuing offset adjustment: -0.008491 Dec 6 09:40:11 crater dntpd[605]: issuing offset adjustment: 0.004089 Dec 6 22:23:50 crater dntpd[605]: issuing offset adjustment: 0.006602 Dec 6 22:43:16 crater dntpd[605]: issuing offset adjustment: -0.002391 Dec 8 13:29:11 crater dntpd[605]: issuing offset adjustment: -0.005005 Dec 11 23:37:00 crater dntpd[605]: issuing offset adjustment: 0.004607 Dec 17 23:11:26 crater dntpd[605]: issuing offset adjustment: -0.005559 Dec 18 23:05:12 crater dntpd[605]: issuing offset adjustment: 0.008101 Dec 3 10:47:13 leaf dntpd[593]: dntpd version 1.0 started Dec 3 10:47:29 leaf dntpd[593]: issuing offset adjustment: 0.027401 Dec 3 11:08:45 leaf dntpd[593]: issuing frequency adjustment: -12.384ppm Dec 3 13:14:49 leaf dntpd[593]: issuing offset adjustment: -0.012258 Dec 3 20:14:44 leaf dntpd[593]: issuing offset adjustment: -0.010502 Dec 10 04:27:05 leaf dntpd[593]: issuing offset adjustment: -0.008231 Dec 16 21:58:56 leaf dntpd[593]: issuing offset adjustment: -0.003460 Dec 17 23:11:18 leaf dntpd[593]: issuing offset adjustment: -0.009111 Dec 18 15:39:10 leaf dntpd[593]: issuing offset adjustment: 0.006555 Dec 3 10:47:12 pkgbox dntpd[583]: dntpd version 1.0 started Dec 3 10:47:28 pkgbox dntpd[583]: issuing offset adjustment: -0.226392 Dec 3 10:52:58 pkgbox dntpd[583]: issuing frequency adjustment: 16.116ppm Dec 3 11:13:59 pkgbox dntpd[583]: issuing offset adjustment: 0.007382 Dec 10 04:28:53 pkgbox dntpd[583]: issuing offset adjustment: -0.008714 Dec 15 02:47:01 pkgbox dntpd[583]: issuing offset adjustment: 0.003445 Dec 17 02:48:19 pkgbox dntpd[583]: issuing offset adjustment: -0.002681 Dec 17 23:08:02 pkgbox dntpd[583]: issuing offset adjustment: -0.010769 Dec 18 09:43:53 pkgbox dntpd[583]: issuing offset adjustment: -0.008604 Dec 18 11:23:34 pkgbox dntpd[583]: issuing offset adjustment: 0.002538