NTP Performance

[Richard Laager]

On 11/21/19 12:55 AM, ASSI via devel wrote:
>> I could try fiddling around with the polling interval. Next steps might
>> be to try raising the polling the interval to 4 and/or lowering it to 1.

> It is generally inadvisable to use too short polling intervals unless
> rthe clock you are disciplining is exceptionally unstable.

Do you have a recommended polling interval for the GPS PPS source? I've
looked at some ADEV charts (in general, nothing generated here)
comparing quartz and GPS, and it seems like maybe I want ~30-60 seconds?

I'm currently running with the values removed (i.e. using the defaults
of minpoll 6 maxpoll 10). It's still at 64. I'm avoiding touching the
server until it's been at least 24 hours of stability.

I tried changing from gpsd SHM to the PPS driver, but then my offset
(which was with SHM too if I added it back) from ntpq -p was -100, which
I believe is milliseconds. That made me wonder if it was catching the
wrong edge of the PPS signal, as the pulse width on this GPS is 100 ms.

Along the way, I ended up finding that I had misconfigured gpsd a bit.
It seems gpsd will handle setting up the PPS line discipline on the
serial port, and it is not necessary to pass /dev/pps0 as a device to
gpsd. So I fixed those issues and changed the SHM from unit 2 to unit 1
like the documentation/examples say to use.

At this point, I'm focusing on proving ntp2.wiktel.com is back to normal
GPS operation and seeing how the polling interval change behaves. Then I
might try to switch from SHM to PPS again.

-- 
Richard