[ntp:questions] ntpd losing sync
agcarver+ntp at acarver.net
Mon Feb 6 16:22:39 UTC 2012
On 2/6/2012 01:12, Dave Hart wrote:
> On Mon, Feb 6, 2012 at 08:35, A C<agcarver+ntp at acarver.net> wrote:
>>> You might also consider switching from gpsd/shm + atom/pps to using
>>> NMEA directly -- at least for testing, if other avenues of diagnosing
>>> the problem prove fruitless.
>> I'll try the splitter this coming weekend when I have an opportunity to set
>> up a second system. The clock on the IPX is set for UTC so no conversions
>> should be necessary.
> That helps, but one still needs to convert HH:MM:SS to seconds since
> midnight to correlate. If you want many eyes on the prize, do it for
> us an point out the correlation of, for example, a spike_detect and
> loopstats entry.
The snippets of the logs were occuring at about the same time (within
seconds of each other) but here is the most relevant parts marked with
the converted time stamp (perhaps the main log file should contain the
time stamps used by the other files?):
ntpd.log (occurs at 21415 seconds):
6 Feb 05:56:55 ntpd: 0.0.0.0 0113 03 spike_detect -0.142499 s
peers (spike_detect at 21415):
55963 21350.985 127.127.22.0 974a -0.000004278 0.000000000 0.000523922
55963 21384.000 127.127.22.0 974a -0.001758997 0.000000000 0.001542449
55963 21416.000 127.127.22.0 974a -0.142499126 0.000000000 0.003439354
55963 21432.000 127.127.28.0 937a -0.168592361 0.000000000 0.004960079
55963 21448.000 127.127.22.0 974a -0.292503723 0.000000000 0.004388269
55963 21480.000 127.127.22.0 974a -0.442512698 0.000000000 0.004862297
55963 21512.000 127.127.22.0 974a 0.372477306 0.000000000 0.005099591
55963 21544.000 127.127.22.0 974a 0.212477028 0.000000000 0.005217774
loops (spike_detect at 21415):
55963 21351.084 0.000011018 -77.659 0.000275145 0.047121 5
55963 21385.000 -0.000009136 -77.659 0.000012402 0.044078 5
55963 21577.000 -0.000004309 -77.659 0.000012402 0.041231 5
55963 21609.000 -0.000003802 -77.659 0.000012402 0.038568 5
55963 21769.000 -0.000002032 -77.659 0.000012402 0.036077 5
55963 21801.000 -0.000001793 -77.659 0.000012402 0.033747 5
>> I guess I can try NMEA for a diagnosis but actually want the GPS to be in
>> SiRF binary because I planned on using the gpsd data elsewhere, too.
> You ignored the "at least for testing". Also I suspect gpsd can
> operate just fine with NMEA input -- I don't see why using gpsd
> implies binary.
No, I didn't ignore "for testing". I can try it for testing after other
things but I'm trying to use a complete configuration change as a last
resort. Yes, gpsd can take NMEA but some data (such as SBAS
corrections) are only available via SiRF binary and not available as
>> Splitting the GPS to another machine will probably be easier.
>> If I set up the clockstats, do I need to configure flag4 on the PPS refclock
>> for it to record PPS data?
> Without fudge flag4 1, refclock_atom logs nothing to clockstats. With
> that flag, it logs each offset (per second, not per poll). I don't
> know why I spend time looking at code to answer such questions. I'm
> getting fed up with handholding.
Actually, I asked because flag4 is documented for most of the other
refclocks but not very well for ATOM. For example, the SHM clock is
very well documented in the online documentation regarding what is
recorded when flag4 is enabled including a sample of the clockstats line
that gets recorded. The ATOM driver just says "record a time stamp"
with no examples of the expected output, what the time stamp means
specifically, if it should recycle in any way, etc. I had enabled it
based solely on the single statement "record a time stamp" but I wasn't
even sure if it was working correctly except for a once-per-second
My first destination for questions like this is the online documentation
rather than the code. Yes, I could dig through the code but a nice
explanation in the documentation similar to the SHM refclock can make a
huge difference in understanding what to do and expect.
More information about the questions