[ntp:questions] Stick to PPS, even if the prefer server fails
mills at udel.edu
Mon Mar 23 03:22:57 UTC 2009
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.
Dave Hart wrote:
>On Mar 21, 1:51 pm, "alkope... at googlemail.com"
><alkope... at googlemail.com> wrote:
>>If Server A loses the GPS signal, it falls back to LOCAL and begins to
>>drift away. In the beginning Server B doesn't care about that and
>>stays to the PPS. But later it disconnects PPS and runs on Server A
>>again. So both servers drift away. In my opinion Server B should stay
>>to the PPS signal. Is there anything I can do about that?
>I believe you're limited to options that would keep the prefer peer
>surviving NTP's clock selection gauntlet. I could be mistaken, but I
>believe PPS with no prefer peer is intended to stop working.
>Dr. Mills' comment "the PPS should still be enabled" confusede me at
>first, but I think he's saying assuming your PPS is disciplining the
>kernel clock directly, that aspect should continue to keep your local
>clock from drifting from its cesium standard during a GPS outage
>despite ntpd eventually losing its PPS(1) peer.
>questions mailing list
>questions at lists.ntp.org
More information about the questions