[Thumbgps-devel] decoding ntp... does anyone really know what time it is?

[Dave Taht <dave.taht@gmail.com>]

I should probably get back on the timenuts list but perhaps someone
here can explain this:

http://www.eecis.udel.edu/~mills/ntp/html/decode.html

So I have a pps configuration of the gpsd configured. Or thought I
did. Actually, in this case, gpsd had failed to start on beagle-1 for
some reason, ntpd started without it, and I started it after ntpd.

I'm still waiting for ntp to pick it up, so far, which I talk to
below. I'm just curious as to how viable tickers evolve over time....

Anyway, a - means it's discarded from the cluster algorithm. Beagle-1
is my gps served ntp server

on a remote client:

ntpq> peer
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-beagle-1        199.102.46.72    2 u  984 1024  377    0.779  -23.343   3.593
*pool-test.ntp.o 127.67.113.92    2 u  937 1024  357   35.216   -4.543   5.157
-d7.hotfile.com  220.183.68.66    2 u  726 1024  377   81.001   -8.452   4.082
-ntp.westbrook.c 120.119.68.211   3 u  830 1024  375   29.350  -11.324  13.744
+208.79.16.124   198.60.22.240    2 u  797 1024  377  123.573  -10.639  12.673
+golem.canonical 193.79.237.14    2 u   83 1024  377  161.633    2.891   8.818

on beagle-1 (after I restarted gpsd)

 ntpq -n -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.28.0    .GPS.            0 l   21   16   76    0.000  302.125   0.858
 127.127.28.1    .GPS1.           0 l    -   16    0    0.000    0.000   0.000
+69.50.219.51    209.51.161.238   2 u  446  512  173   78.353    4.241  15.379
-216.229.0.49    216.229.0.179    2 u  876  512  376  157.278  -14.828   4.858
+2001:4f8:fff7:1 66.220.9.122     2 u  237  512  377   24.358   16.313   7.613
*199.102.46.72   .GPS.            1 u  457  512  333  155.082    0.735   9.664

My assumption is that after a suitable period, the client box will
grok that the beagle-1 box is stratum 1 and move over to it, or are
their other heuristics involved?

After a while, the above became marked with an X (and I think pps
didn't kick in)

root@beagle-1:/var/spool# ntpq -n -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
x127.127.28.0    .GPS.            0 l  123   16  200    0.000  302.125   0.972
 127.127.28.1    .GPS1.           0 l    -   16    0    0.000    0.000   0.000
+69.50.219.51    209.51.161.238   2 u   20  512  367   75.973    2.586  14.346
+216.229.0.49    216.229.0.179    2 u  978  512  376  157.278  -14.828   4.858
-2001:4f8:fff7:1 66.220.9.122     2 u  339  512  377   24.358   16.313   7.613
*199.102.46.72   .GPS.            1 u   20  512  267  140.874  -11.207   6.531


which is  "discarded by intersection algorithmn"

Does
-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html