copied from gpsd users list
hmurray at megapathdsl.net
Fri Mar 20 03:50:18 UTC 2020
>>> The problem at hand is that a user has local PPS and wants that time
>>> to win the startup race, ahead of the more jumpy network chimmers.
>>> It is maybe 1,000x more accurate and stable.
I don't know how to do that.
You might find a good/best way with a lot of trial and error, but the network
is a wonderful source of noise so what works best today may no longer be best
tomorrow and/or may be best only a fraction of the time.
>>> To that end, a user places the PPS at the top of the ntp.conf, with
>>> a short poll time than other refclocks, so that ntpd will select it
ntpd starts the servers in listed order, one second at a time. If you put the
PPS first, it probably won't have any data yet. You may get better results by
putting it a few slots down the list.
>> So, if I may interject for my own clarity. For an ntp server with a
>> properly running GPS and PPS, in a stable environment with reliable
>> network, this would suggest that - regardless of pool*or* peer - it
>> is best not to use iburst?
The "i" in iburst is for initial. It only matters during startup or restart.
Restart covers recovery from clock stepping or that driver being out of touch
for a while. I don't see any reason not to use it.
Why did you say "peer"? We dropped real peer mode ages ago. It acts like
server. If there isn't a warning message, we should add one.
Rick Bollar said:
> Does using the "prefer" option force the local clock to be accepted?
> # PPS Server
> refclock pps unit 0 time1 0 minpoll 0 maxpoll 0 refid PPS flag2 0 prefer
> #Coarse Time GPS Server
> refclock shm unit 1 minpoll 4 maxpoll 4 refid GPSD prefer stratum 1
You have an interesting mix of shm and PPS.
The PPS driver needs some other driver to tell it which second the PPS pulse
goes with. ntpd uses "prefer" for that. It's a hack leftover from ages ago.
We should clean that up.
These are my opinions. I hate spam.
More information about the users