gpsd and ntp

[Tim Cwik-2]

Cross posted, hopefully not inappropriately.

I am using gpsd with a Trimble Thunderbolt to supply time and PPS to
ntpd for a time server.
The Tbolt shows serial output, PPS signal looks ok, and is detected by gpsd.

ntpq -p shows:

# ntpq -p
      remote           refid      st t when poll reach   delay   offset  
jitter
==============================================================================
+nonce.prolixium 209.51.161.238   2 u   24   64  377   46.131   26.478  
59.117
  u15161952.onlin 209.51.161.238   2 u  12h 1024    0  218.935  
-38.878   0.000
  skywiley.com    131.107.13.100   2 u  33d 1024    0   88.930    
2.426   0.000
+redline.mednor. 209.81.9.7       2 u    7   64  377   92.425   21.976  
64.496
  octopus.stnhbr. .STEP.          16 u    - 1024    0    0.000    
0.000   0.000
  SHM(0)          .GPS.            0 l   5h   16    0    0.000  
-641.16   0.001
*SHM(1)          .GPS1.           0 l    4   16  377    0.000    0.024  
0.060
  LOCAL(0)        .LOCL.          10 l    2   64  377    0.000    
0.000   0.001

I never see ntpd use the SHM(0) output from gpsd. The shared memory is
ok, I think, because it does see the PPS time in SHM(1).

My ntp.conf includes:

server 127.127.28.0 minpoll 4 maxpoll 4
fudge 127.127.28.0 refid GPS

server 127.127.28.1 minpoll 4 maxpoll 4 prefer
fudge 127.127.28.1 refid GPS1

I assume I want to be using the GPS time from the serial port through
SHM(0) and that this should be one of the peers and would make my
solution more independent of external time servers should my network
connection fail.

Thanks for any advice.

Tim
N2LTQ
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[David Severt]

Tim;

When I first tried to use gpsd with ntp, I was using Suse 10.2 and had
the same problem.  I did a grep on /var/log for "ntpd" and discovered
that ntpd was having trouble opening the shared memory file that it uses
to get data from gpsd.  The problem was that a security app, called "app
armor" under Suse, was preventing access to the shared memory file.  I
don't recall exactly what I did to fix it but I'm pretty sure I just
went into Yast to look at security issues and that it automatically came
up with a recommended fix that I just had to say "yes" to.  I hope this
points you in the right direction.

Regards,
David Severt


Tim Cwik wrote:

> Cross posted, hopefully not inappropriately.
>
> I am using gpsd with a Trimble Thunderbolt to supply time and PPS to
> ntpd for a time server.
> The Tbolt shows serial output, PPS signal looks ok, and is detected by gpsd.
>
> ntpq -p shows:
>
> # ntpq -p
>       remote           refid      st t when poll reach   delay   offset  
> jitter
> ==============================================================================
> +nonce.prolixium 209.51.161.238   2 u   24   64  377   46.131   26.478  
> 59.117
>   u15161952.onlin 209.51.161.238   2 u  12h 1024    0  218.935  
> -38.878   0.000
>   skywiley.com    131.107.13.100   2 u  33d 1024    0   88.930    
> 2.426   0.000
> +redline.mednor. 209.81.9.7       2 u    7   64  377   92.425   21.976  
> 64.496
>   octopus.stnhbr. .STEP.          16 u    - 1024    0    0.000    
> 0.000   0.000
>   SHM(0)          .GPS.            0 l   5h   16    0    0.000  
> -641.16   0.001
> *SHM(1)          .GPS1.           0 l    4   16  377    0.000    0.024  
> 0.060
>   LOCAL(0)        .LOCL.          10 l    2   64  377    0.000    
> 0.000   0.001
>
> I never see ntpd use the SHM(0) output from gpsd. The shared memory is
> ok, I think, because it does see the PPS time in SHM(1).
>
> My ntp.conf includes:
>
> server 127.127.28.0 minpoll 4 maxpoll 4
> fudge 127.127.28.0 refid GPS
>
> server 127.127.28.1 minpoll 4 maxpoll 4 prefer
> fudge 127.127.28.1 refid GPS1
>
> I assume I want to be using the GPS time from the serial port through
> SHM(0) and that this should be one of the peers and would make my
> solution more independent of external time servers should my network
> connection fail.
>
> Thanks for any advice.
>
> Tim
> N2LTQ
> _______________________________________________
> Gpsd-users mailing list
> Gpsd-users@...
> https://lists.berlios.de/mailman/listinfo/gpsd-users
>
>  

_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Ed Wildgoose-2]

Additionally, although not a solution to your problem, I really like
Chrony over ntp, and with some patches (that are unfortunately not yet
in upstream I think?) it talks very nicely to gpsd.

In particular it can handle (very nicely) being partially connected to
various time servers, internet up/down, synchronising the RTC and also
locks and syncs extremely fast

Good luck

Ed W
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users