[ntp:questions] Why does GPS time diverge from system time?
hart at ntp.org
Sat Apr 14 05:29:20 UTC 2012
On Sat, Apr 14, 2012 at 04:08, Charles Elliott <elliott.ch at verizon.net> wrote:
>> I'd like to see loopstats showing the problem, rather than clockstats.
>> With the NMEA driver as the only selectable source, loopstats will be
>> clearer as it includes the offset instead of requiring subtraction.
> Loopstats is at http://pastebin.com/ZPG894qd; its title is Loopstats. It
> does not show any problem though. The statistics for the offset are (in
> min -0.005050
> max 0.005032
> avg -0.000125
> stdDev 0.001468
> I also put loopstats and clockstats for the week at
> FD41!253&parid=root. Look at the graphs of peerstats. The line at zero is
> the GPS device. The line above it, the one that wanders is a Sure GPS
> device w/o pps. The 3 lines that go from quadrant III to quadrant II are
> three computers connected to 8 stratum 2 servers via ntpd. These shold be
> correct. Hence the GPS device does appear to wander. But is that because
> the GPS device is not influencing the system clock?
> There is no relationship between the difference between system time and GPS
> time shown in the clockstats file and the computed offset in the loopstats
> file. The GPS device may not be influencing the system clock.
Argh. I assumed from your description that you were using a single
NMEA refclock without PPS which was driving the clock, with all other
sources noselect. On that basis, I asked you to use loopstats because
it has the number we want (offset) instead of components from which
one might try to compute offset, and because it would focus on the
single source being used, and not confuse issues with unrelated
sources you have configured with noselect.
Now if I read the tea leaves correctly, I see you have a PPS-providing
refclock which the system clock is being disciplined to match, and
another noselected NMEA-only GPS refclock, which is showing a cyclic
pattern to its offsets that looks like the left-to-right mirror image
of NNNNN, with offsets creeping up essentially linearly to a max, then
falling off a cliff to a minimum, and repeating. I do not see the
"steady divergence" you mentioned at all.
>> As ever, it's known that some GPSes NMEA timing wanders subtantially,
>> that may be part of the reason for what you're seeing.
> This clock does not wander; look at the average, max, min, and Std Dev
The pattern of NMEA offset wander is familiar, others have posted
graphs of NMEA sentence timing relative to PPS which show the same
>> You didn't mention which version of Windows, but the 0.977 minimum
>> delay and jitter values tell me it's Vista or Win7, and ntpd has
>> disabled interpolation because the native Windows clock is advancing
>> once per millisecond, too fast for ntpd's interpolation to be able to
>> schedule enough sampling at 1 msec scheduling precision to accurately
>> correlate the performance counter timescale with the system clock's.
>> As a result, ntpd is using the system clock directly, as it will have
>> reported in its startup log messages, and as can be seen with ntpq -c
>> "rv 0 precision" which will be -10, or ~1 msec.
>> With the local clock precise only to 1 msec, ntpd is refusing to
>> respect the noise measured as apparent delays of less than 0.977 ms (or
>> 2**-10 sec), instead forcing delays to have a minimum of 0.977.
>> Similarly, given the low precision clock, jitter figures less than
>> 0.977 ms would be fiction, the clock can't measure differences smaller
>> than that.
>> I wish I could tell you what causes your system clock to switch from
>> its boot-time default of ticking every 15.6 msec to once every msec,
>> but so far the trigger(s) for that behavior by Vista and Win7 remain a
>> mystery. The good news is Win8 provides an alternate high-precision
>> system clock, and the last few ntp-dev snapshots will use it. On Win8,
>> ntpd should perform comparably to the many other systems with high-
>> precision system clocks.
> You are right with all three paragraphs here. I took out
> NTPD_USE_INTERP_DANGEROUS=1 to attack another problem: Dragon
> Naturally Speaking (DNS) was grossly misrecognizing words and leaving
> out whole phrases. Taking out NTPD_USE_INTERP_DANGEROUS seemed like
> a good place to start. But that turned out not to be DNS's problem.
> When I put NTPD_USE_INTERP_DANGEROUS=1 back in the system, the delay
> And jitter went back to their normal accuracy. This is Win 7.
Now that is intriguing for me. As the name suggests, I would expect
forcing on use of ntpd's Windows port interpolation with
NTPD_USE_INTERP_DANGEROUS when the Windows clock is ticking at 1 msec
precision would result in degraded timekeeping due to failing (and
flailing) interpolation. I do not understand how it could actually
improve the performance. If I did, I'd like to make ntpd use
interpolation without forcing the choice in that situation.
More information about the questions