[ntp:questions] Stick to PPS, even if the prefer server fails

David Mills mills at udel.edu
Mon Mar 23 16:08:09 UTC 2009


Somehow using an HP 5071 to discipline the time without kernel support 
seems bizarre, but it could be done in a spacecraft with only 
intermittent contact with Earth. At the default rate of dispersion 
increase of 15 us/s and distance threshold at the default 1.5 s, the 
client will coast about 2.8 h. The tos maxdist 5 command would increase 
that to 3.9 h. The downside to this is that this also reduces the number 
of measurements when first synchronizing. Note that the kernel has no 
distance threshold, so in principle could go forever without a prefer peer.

The distance metric is intended as a maximum error statistic and 
includes components due to roundtrip delay, dispersion, absolute offset 
and RMS jitter. It was never intended for use as a holdover for absentee 
prefer peers. There are other ways to do this, all with unintended side 
effects. A related problem has occured with simulated Moon missions, in 
which the roundtrip light time is over 2 s. An increase in distance 
threshold to 3 s fixes this, but something else is necessary for 
missions beyond the Moon.


Dave Hart wrote:

>Dr. Mills,
>Thank you for your confirmation.  The original poster should be
>satisfied, assuming their kernel time is being disciplined directly by
>their cesium standard.  If they are unable to use the kernel
>discipline for some reason, could they tinker _max_disp (I don't know)
>to keep the upstream server with GPS surviving longer?  If there is no
>maximum dispersion tinker, "tinker dispersion 5" on the upstream
>server with GPS should similarly delay the inevitable.  (The default
>is 15, units part per million)
>Dave Hart
>On Mar 23, 3:22 am, mi... at udel.edu (David Mills) wrote:
>>Once the kernel PPS is lit, it will stay lit even if the daemon loses
>>the prefered soure or even dies.This is the intended behavior, which I
>>confirmed just now. Veriy that  ntptime shows PPSTIME lit after the
>>daemon loses the prefer peer or is stopped.
>>By the way, with just a remote peer and PPS, the intersection algorithm
>>is quite picky if the remote peer strays a bit. Use tinker mindisp to
>>something higher, like .05 s.
>questions mailing list
>questions at lists.ntp.org

More information about the questions mailing list