On 2014-12-11, Sander Smeenk <ssme...@freshdot.net> wrote: > Quoting Rob (nom...@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 timing. > > 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. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
