copied from gpsd users list

[Hal Murray]

>>> 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
>>> first.

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.