[ntp:questions] ntpd losing sync

A C 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[4538]: 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 
0.000061035
55963 21384.000 127.127.22.0 974a -0.001758997 0.000000000 0.001542449 
0.001758229
55963 21416.000 127.127.22.0 974a -0.142499126 0.000000000 0.003439354 
0.142249996
55963 21432.000 127.127.28.0 937a -0.168592361 0.000000000 0.004960079 
0.141854415
55963 21448.000 127.127.22.0 974a -0.292503723 0.000000000 0.004388269 
0.276412286
55963 21480.000 127.127.22.0 974a -0.442512698 0.000000000 0.004862297 
0.394614125
55963 21512.000 127.127.22.0 974a 0.372477306 0.000000000 0.005099591 
0.524797280
55963 21544.000 127.127.22.0 974a 0.212477028 0.000000000 0.005217774 
0.372601026

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 
NMEA sentences.

>
>>   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 
recording.

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 mailing list