The reason for the additional GPS strings is this system will actually be moving around and we also need to get the position and fix quality information through gpsd.
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. 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. Thanks, Scott -----Original Message----- From: Miroslav Lichvar [mailto:mlich...@redhat.com] Sent: Wednesday, November 27, 2013 1:44 AM To: chrony-users@chrony.tuxfamily.org Subject: Re: [chrony-users] kernel PPS troubleshooting On Tue, Nov 26, 2013 at 08:49:19PM -0500, Battocchi, Scott L. wrote: > Bill, > Thanks for taking an initial look. I've added my system to our network to > compare our GPS time with the general NTP pool and it looks like our GPS > could be right on the edge of that 0.4s window. I'm going to let it run for > a bit like this and report back after trying a larger offset for our SHM > refclock. The receiver I am using is an MTK3339 if anyone else has a > standard offset they use (default speed and strings (9600 8n1 with GGA GSA > RMC VTG and VSG enabled). Yes, from the log it looks like the SHM and PPS sources are too far from each other (large offdiff value). Also, the GPS source might be too jittery to be used reliably as the locking reference for PPS. One way to find out which one is wrong is to add a good NTP source as the reference, add the noselect option to the GPS and PPS sources (without any locking) and observe the offset values in the refclocks log or chronyc sourcestats output. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
