[ntp:questions] NTP & PPS, part 2 ;)

William Unruh unruh at invalid.ca
Fri Dec 12 01:00:05 UTC 2014

On 2014-12-11, Sander Smeenk <ssmeenk at freshdot.net> wrote:
> Quoting Rob (nomail at example.com):
>> > Debian wheezy's packaged ntpd does include PPS support.  I am currently
>> > running ntpd from that stable repository and running the ATOM refclock
>> > (22).  The pps-tools package is also available in the repository for
>> > direct installation.
>> That must be new.  There was no PPS support in the Wheezy binaries a
>> couple of months ago.  A bug about this was filed, but nothing happened.
> Aparently all that is missing in the ntp package (in Ubuntu?) is a
> Build-Depends on the pps-tools package to provide timepps.h in
> /usr/include/sys/
> This doesn't even introduce new binary dependencies. The pps-tools
> package isn't needed after compilation so i dont see why this isn't
> fixed yet. ;)

It is one of those pissing matches. Ntp thinks the os should provide
timepps.h, while the others think ntpd should provide it if they need
it. As a result the users get screwed while the self-righteous can
continute in glory. Just like with cdrecord. 

> I'm done:
> oPPS(0)  .PPS.  0 l  -  16  377  0.000  -0.001  0.002
> I'm getting about that precision with my Garmin 18x LVC and 98 meters(!)
> of cable length.

The problem is that the main source of gjitter is the interrupt handling
of the operating system. That introduces about 1us of jitter into the

> A big thanks to those of you that participated in this thread.
> You might want to hear that i got it running now with ref clock 20 and
> 22. GPSd is no longer at play and i have the (what i call) "true" PPS
> sync with 'oPPS(0)' in my peer list now.

No idea what "true: PPS is supposed to be. gpsd also uses "true" PPS. 
And the problem is the timestamping of the PPS transition by the system-- that 
is where all the problems lie. And that is essentially the same for
kernel PPS, gpsd, ....

> -Sndr.

More information about the questions mailing list