[ntp:questions] ntpd + GPS + PPS + Linux (Ubuntu Lucid)

Stephan Skrodzki skrodzki at stevekist.de
Wed Jun 8 08:11:44 UTC 2011

Am Dienstag, den 07.06.2011, 20:24 +0000 schrieb Rob:
> >> 
> >> gpsd plus ntpd does not require any PPS support in the kernel.
> >> there is no specfic PPS support via SHM but the gpsd just provides a
> >> pretty accurate clock to ntpd.  When your system is not overloaded
> >> (CPU loading always around or over 1.00) there should be no problem
> >> with sync
> >
> > Overload is not the case. After what you wrote, I had a short look at
> > the gpsd ntpshm code and saw, that the pps shm part also inserts the gps
> > time from the gps, so: why do I need the gps part of the shm at all?
> I think you mean "the pps part..."

No, I meant the gps part... as I looked into the code of gpsd my vague
understanding is, that it takes gettimeofday, when a pps arrives, but
then does some magic with the gps serial input (in ntpshm.c). I do not
really understand, why this is necessary, as I would also like to use
this as a pps only solution, where I get a pps from an external source
without any gps (and therefore no time from gps). But I will ask this on
the gpsd mailing list.

> >
> > What confuses me is the following behaviour with only 
> >
> > server minpoll 4 maxpoll 4 prefer 
> > fudge refid PPS 
> >
> > from syslog:
> >
> > Jun  5 03:10:46 na-stephan ntpd[8583]: no servers reachable
> > Jun  5 03:11:02 na-stephan ntpd[8583]: synchronized to SHM(1), stratum 0
> > Jun  5 03:11:19 na-stephan ntpd[8583]: time reset -0.999972 s
> > Jun  5 03:12:29 na-stephan ntpd[8583]: synchronized to SHM(1), stratum 0
> This is a bit worrying.  It can be that gpsd has guessed the wrong
> time to relate to the PPS pulse.
> You have to know that the SHM interface cannot transfer raw PPS info.
> It can only transfer absolute time, which PPS does not deliver.
> Therefore gpsd uses a trick: when a PPS pulse arrives, it checks if
> the system clock is close to the seconds mark, and if so it sends
> the absolute time of the closest second.  When the system clock is far
> away from correct time, it could guess the wrong second.
> When I wrote that code, I set a maximum clock error of 400ms before
> the PPS SHM interface is "enabled".  As long as the clock is outside
> that margin, the PPS simply is dead and the GPS SHM interface (SHM(0))
> first has to "pull" the system within that margin.

This functionality I have seen in libgps-core... and I guessed it was
you reading your name in it :-) 

> You could try raising the issue on the gpsd developer mailing list,
> they are quite active.

I will do so. First I have to build an actual version and use that for
testing, I guess ;-)

Thanks for your great help!


More information about the questions mailing list