[ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
unruh
unruh at invalid.ca
Wed Mar 21 15:36:44 UTC 2012
On 2012-03-21, Ron Frazier (NTP) <timekeepingntplist at c3energy.com> wrote:
> On 3/21/2012 2:49 AM, David J Taylor wrote:
>>
>> "Ron Frazier (NTP)" <timekeepingntplist at c3energy.com> wrote in message
>> news:4F692255.2020304 at c3energy.com...
>>> On 3/20/2012 11:21 AM, David J Taylor wrote:
>> []
>>>> You /will/ see variation in the serial output from the Sure device,
>>>> as you will in many NMEA devices. For the Sure device, one
>>>> measurement is here:
>>>>
>>>> http://www.leapsecond.com/pages/MG1613S/
>>>>
>>>> under the heading "NMEA Latency". The graph here is 100
>>>> milliseconds full scale.
>>>>
>>>> http://www.leapsecond.com/pages/MG1613S/nmea-jitter-1.gif
>>>>
>>>
>>> That's funny, there's this line in the text.
>>>
>>> "In a 15 minute run (900 seconds) the mean latency was 350.2 ms with
>>> a standard deviation (jitter) of 10.7 ms. "
>>>
>>> Then there's the graph, which seems to show a variance in NMEA start
>>> time of 75 ms or so. The two seem to contradict each other.
>>
>> How so? Are you taking the peak-to-peak figures from the graph and
>> comparing it to the standard deviation? SD isn't a peak-to-peak value.
>>
>>> You already mentioned the Garmin previously, and the Sure now, and I
>>> have reports of similar NMEA drifting behavior from other SIRF units.
>>> So, it appears that most, if not all GPS's exhibit a variance in the
>>> timing of NMEA data of 50 to 120 ms or so. That would definitely put
>>> a limit on what you could do with NMEA only data.
>>
>> Yes, in typical GPS receivers the NMEA data is only accurate to a
>> second - it says where the unit was at the UTC second preceding the
>> data. I don't believe that jitter in NMEA output time is limited to
>> one particular chipset.
>>
>> (Is jitter RMS, SD, peak-to-peak?).
>>
>
> I noticed that Dave Hart later posted this reply to your question. I'll
> reference that below.
>
> NTP's jitter is root mean squares of offsets from the clock filter
> register (last 8 responses, more or less).
Strange, because ntp then takes that entry of those 8 with the shortest
roundtrip time and uses only it to drive the ntp algorithm. Thus on the
one hand it is using it as a measure of jitter and on the other hand
saying it does not trust most of those values, with a distrust so deep
it throws them away. Why would you be reporting anything for a set of
data you distrust so deeply.
>
>
>
>> Cheers,
>> David
>
> Perhaps I've been misusing some of the terms. There appear to be 5
> items we could discuss / graph.
>
> A) The moment to moment offset of my PC's clock from the GPS clock when
> I sample it. In my case, this is NMEA data. This is where I've been
> reporting + / - 10 ms accuracy. I, perhaps wrongly, thought this peak
> to peak range, or maybe half of it, was the jitter.
>
> B) The longer term (a few days) variance of the NMEA data from UTC. You
> could call it variance, wobble, drift, I don't know if there is an
> official name for it.
>
> C) What your ntp plotter plots as the red line on the jitter tab with a
> loopstats file. Not sure how that's derived.
>
> D) What your ntp plotter plots as the black line on the jitter tab with
> a loopstats file, a weighted moving average, presumably of the red line.
>
> E) What the Meinburg Time Server reports for each peer as jitter. This
> is probably the same data as NTPQ - p.
>
> Probably, C and E are the only ones that match Dave Hart's definition
> quoted above.
>
> For my personal purposes, an RMS value doesn't do me as much good. I am
> mainly concerned with A and B. My main concerns are, how far my PCs'
> clocks are off from each other, and how far they're off from UTC. So, I
> could say the following to characterize my GPS system.
>
> 1) My PC clock is almost always within + / - 10 ms of GPS time due to
> short term offsets from the GPS NMEA data.
>
> 2) My GPS time is almost always within + / - 70 ms of UTC time due to
> longer term variance in the timing of the NMEA data.
>
> and consequently
>
> 3) My PC clock is almost always within + / - 80 ms (adding the two) of
> UTC time due to short term and longer term changes in the NMEA data.
>
> I have no idea what the proper names are to apply to these parameters.
>
> Sincerely,
>
> Ron
>
>
More information about the questions
mailing list