PPS driver should be (more easily/reasonably) usable with network sources
In #537 (closed), I asked, "Is there a way to use the PPS with network sources? In other words, can ntpd be configured to use network sources to get the time as per normal, and then use the PPS to tighten up the precision on the start of the second?"
I am splitting that out into its own issue.
@hal.murray replied:
I think so, but I haven't done it.
Use the PPS driver. It needs a prefer-ed system to get the rough time. Normally, that is the serial channel but a network server should work.
You might want to prefer several network servers. That seems silly, but if it works, it should keep working if one of the network servers goes down. Again, I haven't tried it.
I replied as follows:
That's what I figured, and tried after posting this issue. It seems to work (though I haven't tested the server failure scenario). I'm not sure if marking them all as preferred has negative impacts on the clock selection algorithm.
In my limited testing, ntpd did, unsurprisingly, prefer the first server marked preferred in ntp.conf. The jitter on all my hand-selected clocks was pretty similar, so I sorted them in ntp.conf in order of increasing (absolute value of) offset. At least that way it's preferring the normally best one.
docs/prefer.txt says (emphasis added):
- If there is a PPS driver and the system clock offset at this point is less than 0.4 s, and if there is a prefer peer among the survivors or if the PPS peer is designated as a prefer peer, the PPS driver becomes the system peer and its offset and jitter are inherited by the system variables, thus overriding any variables already computed. Note that a PPS driver is present only if PPS signals are actually being received and enabled by the associated driver.
That seems to suggest that marking the PPS driver as preferred should allow it to be used. Note that this is an ORed condition with "if there is a prefer peer among the survivors", which is what both you and I expected (and what works). I'm not sure if this is a bug in the documentation, but it might be useful to make the code match this or something similar.
I further replied:
I'm not sure if marking them all as preferred has negative impacts on the clock selection algorithm.
To answer my own question, probably yes. Prefer peers are immune from elimination due to jitter: https://gitlab.com/NTPsec/ntpsec/blob/master/ntpd/ntp_proto.c#L1767
I am currently testing the following patch in production: pps-prefer-2.patch
This version is based on top of the simplification here: !886 (merged)