[ntp:questions] ntpd connect gpsd shared memory driver

Rob nomail at example.com
Tue Jun 18 18:28:15 UTC 2013

Richard Cagley <rcagley at gmail.com> wrote:
> On Tue, Jun 18, 2013 at 9:27 AM, Rob <nomail at example.com> wrote:
>> As I wrote before, your ntp config is not correct.  please copy it
>> from the docs.  However, that is not the cause of the problem.
>> (it would be the cause of severe inaccuracy once you obtain NMEA data
>> as you are not using PPS)
> yeah, figured I'd walk before I ran so I tried to make my ntp.conf file as
> simple as possible to at least get some timing info, which thanks to your
> and AC's help I now have.
> ok, now onto pps. I went here
> http://gpsd.berlios.de/gpsd.html
> ...and am now using this as my ntp.conf
> ---
> server minpoll 4 maxpoll 4
> fudge time1 0.420 refid GPS
> server minpoll 4 maxpoll 4 prefer
> fudge refid GPS1
> ---
> But, sadly no pps sync...
> ---
> / # ntpq -p
>      remote           refid      st t when poll reach   delay   offset
>  jitter
> ==============================================================================
> *SHM(0)          .GPS.            0 l    7   16  377    0.000    0.048
> 0.005
>  SHM(1)          .GPS1.           0 l    -   16    0    0.000    0.000
> 0.000
> ---
> I have pps debug output built into the kernel and can see pps events on the
> console while I look at gpsd output
> ---
> PPS event at 9862
> PPS event at 9962
> PPS event at 10062
> PPS event at 10162

Well, gpsd does not use kernel pps.  It puts the pps time into the
second SHM segment and lets ntpd pick it up there.  This was coded
in the days that Linux kernels often came without pps support and
additional patches would have to be applied.
I'm not too familiar with kernel pps or how you tell the kernel where
to look for the pps, and if this can interfere with gpsd.
Maybe gpsd has been updated to recognize kernel pps and stay out of
the way, but it does not look like it in your debug log.
(it still creates the pps thread)
I would try removing the kernel pps config while you use gpsd, or only add
it after it has been shown to work without it.

> Sorry, this is so long, but here's a dump of the gpsd output. There are
> several things that concern me, such as some of the warning, but not sure
> of the severity
> / # gpsd -bn -N -D5 /dev/ttyO0
> gpsd:INFO: launching (Version 3.7)
> gpsd:IO: opening IPv4 socket
> gpsd:INFO: listening on port 2947
> gpsd:PROG: NTPD shmat(0,0,0) succeeded, segment 0
> gpsd:PROG: NTPD shmat(32769,0,0) succeeded, segment 1
> gpsd:PROG: NTPD shmat(65538,0,0) succeeded, segment 2
> gpsd:PROG: NTPD shmat(98307,0,0) succeeded, segment 3
> gpsd:PROG: shmat() succeeded, segment 131076
> gpsd:PROG: shared-segment creation succeeded,
> gpsd:PROG: PPS thread launched
> gpsd:INFO: NTPD ntpd_link_activate: 1
> gpsd:INFO: stashing device /dev/ttyO0 at slot 0
> gpsd:PROG: no etc/gpsd/device-hook present, skipped running ACTIVATE hook
> gpsd:INFO: opening read-only GPS data source type 2 and at '/dev/ttyO0'
> gpsd:PROG: PPS Create Thread gpsd_ppsmonitor
> gpsd:PROG: PPS chrony socket /var/run/chrony.ttyO0.sock doesn't exist
> gpsd:INFO: PPS cycle: 631139111, duration: 631139111 @ 1371576962.280231

Strang that this is the last that is heard from PPS, while in your
earlier log there were a few PPS pulses that looked OK.
(but then they were not used because no valid serial data was coming in)
Did you change something?

More information about the questions mailing list