Date: Tue, 19 Dec 2006 11:43:53 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Jeremy Chadwick <koitsu@freebsd.org> Cc: Michael Proto <mike@jellydonut.org>, freebsd-stable@freebsd.org Subject: Re: ntpd flipping between PLL and FLL mode Message-ID: <200612191943.kBJJhrVM059792@apollo.backplane.com> References: <20061219124151.GA33385@icarus.home.lan> <20061219132032.GA66632@slackbox.xs4all.nl> <45880BA6.80907@jellydonut.org> <20061219165741.GA40101@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200612191943.kBJJhrVM059792>