ntpd flipping between PLL and FLL mode

Matthew Dillon dillon at apollo.backplane.com
Tue Dec 19 11:55:38 PST 2006


: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



More information about the freebsd-stable mailing list