[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