[ntp:questions] ntpd connect gpsd shared memory driver

David Taylor david-taylor at blueyonder.co.uk.invalid
Tue Jun 18 18:48:42 UTC 2013


On 18/06/2013 18:54, Richard Cagley wrote:
[]
> after about 5min...
> / # ntpq -p
>       remote           refid      st t when poll reach   delay   offset
>   jitter
> ==============================================================================
> *SHM(0)          .GPS.            0 l    4   16  377    0.000   11.086
> 0.992
>   SHM(1)          .GPS1.           0 l    -   16    0    0.000    0.000
> 0.000
> +clock1.redhat.c .CDMA.           1 u   12   64   37   79.170  -169.23
> 3.578
> -a1.hotfile.com  209.51.161.238   2 u    7   64   37   59.899  -172.68
> 3.375
> +200.140.8.72.in 64.147.116.229   2 u   11   64   37    7.124  -170.26
> 1.946
> -ec2-50-16-231-1 209.51.161.238   2 u   11   64   37   72.309  -172.73
> 1.987
> -nbg1.shellvator 209.51.161.238   2 u    7   64   37   74.942  -173.58
> 7.111
>
> It's not very close I suppose. Maybe I just need to be patient? Unclear me
> how close the time needs to be for pps to "kick in"

Progress!

Now you can take the average of the offset values, say -171 
(milliseconds) in round numbers, and change the ntp.conf to read:

   server 127.127.28.0 minpoll 4 maxpoll 4
   fudge 127.127.28.0 time1 0.171 refid GPSD

This will make the serial data be approximately in sync with the 
external servers.  Ideally, average over a few minutes, but it doesn't 
need to be that exact unless you will have no PPS signal.

I just did the same on my Raspberry Pi test server:

   http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html#user-mode

How are you feeding the PPS data into the system?

-- 
Cheers,
David
Web: http://www.satsignal.eu



More information about the questions mailing list