| RE: [chrony-users] kernel PPS troubleshooting |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
On Wed, 27 Nov 2013, Battocchi, Scott L. wrote:
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)
Hard to read. The vertical axis is what? seconds?
The tick marks all lie on top of each otehr, so it is hard to figure out what
is going on.
It looks like using the remote ntp sources disciplines the clock to within
better than 10ms (it should be good to about 50 micro, not milli, seconds
unless you have a really bad network.)
I agree on the second graph, the behaviour of the pps is bizarre. It is really
not clear why the pps should suddenlyhave .3 sec offset. The time on the
computer should coast far far better than that. In fact, the gps should only
really be necessary in order to get the system time to within a few hunndred
ms, and after that the PPS should be able to discipline the clock all on its
own (in 16 sec the system clock should not get to more than a ms away from the
true time even free running).
Ffor pps to suddenly indicate .3ms offset would imply that your clock drifted
at 20000PPM which is absurd. So either there is something really seriously
wrong with your system clock (eg some other program is coming in and altering
the clock behind chrony's back) or there is a severe bug in chrony (but I run
chrony with a PPS-- but my own driver and I see offsets of 10 micro seconds,
not 300 milliseconds) or with the PPS driver (but then why is the first graph
where the PPS does not discipline the clock showing none of those absurd
jumps.)
Note that I also find it weird that your gps time fluctuates by almost 1
second peak to peak. It really really should be much better than that.
What do the refclock, measurement and statistics logs show for those times when the PPS
offset jumps so much?
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:mlichvar@xxxxxxxxxx]
Sent: Wednesday, November 27, 2013 1:44 AM
To: chrony-users@xxxxxxxxxxxxxxxxxxxx
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-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.
--
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 | www.theory.physics.ubc.ca/
--
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.