[ntp:questions] NTP & PPS, part 2 ;)
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
> 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, ....
More information about the questions