Re: dntpd

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:you are checking for (1) in client_check().  The quorum check might be su=
:fficient for (2), however when declaring a server as "insane", we might b=
:e loosing information.  Of course the +/- 30 seconds tolerance right now =
:is way too high, best would be sub-second.

    And so I say in the comment.  Sub-second is definitely what we want
    there, but I don't want to blow it up for people on modem connections
    so I'm think something like 0.5 seconds.  It's just a sanity check,
    really.

:The point is, the best jitter-free time source is worth nothing if it is =
:off one second.  Yes, when running an ntpd which also does frequency corr=
:...
:2. Select the median offset of the remaining servers' samples (not averag=
:es)
:3. Now however, we might have selected a jittery source, so search up
:   and down to find a "better" server:  one which has the best samples.  =
:I'd try
:   a sum of quadratic differences to the selected "best temptative offset=
: (2)"
:   to select the best server (jittery servers will more likey drop out un=
:less
:   they are significantly closer to the offset).
:4. using this selected server, I'd take the median (never the average, av=
:erages
:   smear errors) of the samples of this server.
:
:Maybe we should run some traces on the received packets and then evaluate=
: different algorithms (best tracking the real time using a radio clock in=
: parallel).
:
:cheers
:  simon

    When I run dntpd in debug mode with 8 of us.pool.ntp.org's sources
    an extract the offsets, this is what I get after 10 minutes of sampling:

dntpd -F -d -l 4 -f /etc/dntpd.conf

(hacked up output)
off=+0.015458 slope +0.000106 yint +0.03 corr +0.996176 freq_ppm +106.04 stddev 0.000393
off=+0.008142 slope +0.000102 yint +0.02 corr +0.998817 freq_ppm +102.14 stddev 0.001171
off=+0.003510 slope +0.000108 yint +0.02 corr +0.995592 freq_ppm +107.65 stddev 0.000233
off=-0.000043 slope +0.000102 yint +0.02 corr +0.999995 freq_ppm +102.26 stddev 0.000016
off=-0.003430 slope +0.000107 yint +0.01 corr +0.999781 freq_ppm +107.44 stddev 0.001419
off=-0.007099 slope +0.000105 yint +0.01 corr +0.997070 freq_ppm +104.53 stddev 0.000057
off=-0.014571 slope +0.000105 yint +0.00 corr +0.995904 freq_ppm +104.86 stddev 0.000013
off=-0.015090 slope +0.000102 yint +0.00 corr +0.999548 freq_ppm +102.28 stddev 0.000222

    That's the raw output from the linear regression sorted by offset.

    On the bright side, dntpd has no problem calculating the frequency
    drift after 10 minutes.  Look at those wonderful numbers... it
    has it down to 3 or 4 parts per million (3 or 4 uS per second).

    Just for the hell of it I put all 15 of pool.ntp.org and all 15 of
    us.pool.ntp.org's time sources in my dntpd.conf.  Ready?  Here is
    what it looks like after 10 minutes:

off=+0.025647 uoff=+0.089388 slope +0.000103 yint +0.02 corr +0.999987 freq_ppm +103.28 stddev 0.000274
off=+0.022657 uoff=+0.086397 slope +0.000103 yint +0.02 corr +0.999953 freq_ppm +102.76 stddev 0.000139
off=+0.017995 uoff=+0.081774 slope +0.000104 yint +0.01 corr +0.999668 freq_ppm +103.53 stddev 0.000046
off=+0.016187 uoff=+0.079927 slope +0.000104 yint +0.01 corr +0.999180 freq_ppm +103.58 stddev 0.000894
off=+0.013014 uoff=+0.076755 slope +0.000103 yint +0.01 corr +0.999982 freq_ppm +102.97 stddev 0.000240
off=+0.010906 uoff=+0.074646 slope +0.000102 yint +0.00 corr +0.999972 freq_ppm +102.10
off=+0.008651 uoff=+0.072431 slope +0.000104 yint +0.00 corr +0.999991 freq_ppm +104.22 stddev 0.000426
off=+0.008274 uoff=+0.072014 slope +0.000105 yint -0.00 corr +0.998512 freq_ppm +105.09 stddev 0.000651
off=+0.006000 uoff=+0.069741 slope +0.000103 yint -0.00 corr +0.999976 freq_ppm +103.15 stddev 0.000235
off=+0.003832 uoff=+0.067588 slope +0.000103 yint -0.00 corr +0.999980 freq_ppm +102.56 stddev 0.000057
off=+0.003539 uoff=+0.067318 slope +0.000104 yint -0.00 corr +0.999965 freq_ppm +104.00 stddev 0.000100
off=+0.003278 uoff=+0.067058 slope +0.000103 yint -0.00 corr +0.999981 freq_ppm +103.13 stddev 0.000139
off=+0.002149 uoff=+0.065890 slope +0.000106 yint -0.01 corr +0.999830 freq_ppm +105.83 stddev 0.000110
off=+0.001512 uoff=+0.065250 slope +0.000103 yint -0.01 corr +0.999239 freq_ppm +102.58 stddev 0.000450
off=+0.001466 uoff=+0.065193 slope +0.000081 yint +0.00 corr +0.626335 freq_ppm +081.34 stddev 0.002604
off=+0.000198 uoff=+0.063939 slope +0.000102 yint -0.01 corr +0.999970 freq_ppm +102.28 stddev 0.000426
off=-0.000091 uoff=+0.063650 slope +0.000101 yint -0.00 corr +0.999390 freq_ppm +100.66 stddev 0.002487
off=-0.001574 uoff=+0.062166 slope +0.000106 yint -0.01 corr +0.998864 freq_ppm +105.67 stddev 0.000349
off=-0.001781 uoff=+0.061960 slope +0.000076 yint +0.00 corr +0.589265 freq_ppm +076.36 stddev 0.000309
off=-0.002044 uoff=+0.061695 slope +0.000103 yint -0.01 corr +0.999863 freq_ppm +103.21 stddev 0.000192
off=-0.003443 uoff=+0.060299 slope +0.000103 yint -0.01 corr +0.999986 freq_ppm +102.62 stddev 0.000037
off=-0.003540 uoff=+0.060217 slope +0.000108 yint -0.01 corr +0.998497 freq_ppm +108.23 stddev 0.001595
off=-0.006299 uoff=+0.057443 slope +0.000102 yint -0.01 corr +0.999570 freq_ppm +102.01 stddev 0.000057
off=-0.007387 uoff=+0.056393 slope +0.000106 yint -0.01 corr +0.997239 freq_ppm +105.99 stddev 0.004052
off=-0.007648 uoff=+0.056093 slope +0.000102 yint -0.01 corr +0.999995 freq_ppm +102.30 stddev 0.000188
off=-0.008628 uoff=+0.055114 slope +0.000103 yint -0.02 corr +0.999968 freq_ppm +103.14 stddev 0.000087
off=-0.013917 uoff=+0.049825 slope +0.000104 yint -0.02 corr +0.898742 freq_ppm +103.65 stddev 0.004901

    That's a lot of data.  Again, the frequency drift calculation is
    perfect (the two 'dead' samples have aweful correlations so dntpd knows
    they are bad).

    The offsets go from +25ms to -14ms.  I see a pattern with the yintercept
    again, but it could just be an artifact of the way the linear regression
    operates relative to current real time, and while the pattern is a U
    shaped curve in the 27 time sources output, it's a straight line in the
    8 time sources output so ... maybe not something that I can use.

    I'll have to get a better idea of the meaning of the y-intercept in a
    linear regression.  When I wrote the manual page for dntpd I described
    a non-zero y-intercept as indicating a 'shift' in the time source.  There
    might be some relationship to network lag.

    Note that the standard deviation for the +25ms server is very low, and
    also has a very good correlation.  No help there... it's a very stable
    time source.

						-Matt