Re: [chrony-users] kernel PPS troubleshooting

[ Thread Index | Date Index | More Archives ]

On Thu, 28 Nov 2013, Miroslav Lichvar wrote:

On Wed, Nov 27, 2013 at 04:06:58PM -0500, Battocchi, Scott L. wrote:
I ran the GPS while connected to a handful of ntp servers and saw that my gps offset (originally 0.180) was too low, so I bumped it up to 0.530 for the next two tests.  I've attached plots of the offset as recorded in the statistics.log file, if there are other metrics that would be useful I'm happy to graph them and send them out.
ntp.png is with 5 pool servers and the GPS set to noselect (PPS is not locked to anything, but is selectable)
gps.png is after the ntp test but back to just using the GPS and PPS, it looks like sometimes GPS gets selected as the source forcing the PPS signal to look like it is drifting relative to the system.

That looks similar to what I see with with a Garmin 18x LVC. This is a
capture 30 hours long I did some time ago (the NMEA source's offset
value was set to 0.5):

Is this the nmea time or the PPS time? And is the vertical axis seconds or
milliseconds? The problem in his case is that the PPS signal is occasionally
(but far too often) off by almost .3 sec. That is rediculous. And it is only
when the gps-nmea and the PPS are the only sources.

I see nothing like that with my Sure gps with PPS driving chrony. On the other
hand I use a "self rolled" pps interrupt driver on the parallel port, not the
Linux supplied serial port driver. But the graph where he runs the PPS together with the external ntp sources
shows no sign of that kind of absurd jumps in the PPS time, so that would
suggest that the interrupt handler is OK.

Since gpsd has added support for kernel PPS, I think it's better to
use the SHM 1 or SOCK source instead of PPS. Let it handle the HW
details and pair the PPS and NMEA samples.

I think a portion of my original confusion was that the chronyc sources command was indicating that the pulse had never been seen, as opposed to it being seen and ignored.  I need to compare the GPS logs with the chrony logs to see if the changing offset is a function of the number of satellites in view, otherwise I don't have a great explanation for the wander seen in the ntp plot.

From what I remember from other discussions about NMEA timing, it
mainly depends on how is the firmware implemented and the number of
visible satellites may have nothing to do with it.

William G. Unruh   |  Canadian Institute for|     Tel: +1(604)822-3273
Physics&Astronomy  |     Advanced Research  |     Fax: +1(604)822-5324
UBC, Vancouver,BC  |   Program in Cosmology |     unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1     |      and Gravity       |

To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject. For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.

Mail converted by MHonArc 2.6.19+