[ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

Ron Frazier (NTP) timekeepingntplist at c3energy.com
Sat Mar 17 01:06:35 UTC 2012


PPS to prior messages.  I knew I'd remember this after I hit send the 
last time.

You probably want to do any long term graphs starting right after 
powering off the GPS and back on.  If your GPS NMEA start time is 
wandering, that will give you a baseline for comparison which is 
consistent.  Also, once you've accumulated enough graph to see where the 
internet servers are relateive to the GPS, you can set the fudge time2 
parameter to align the GPS time offsets with the average server time 
offsets.  If you do that and restart and wait a while, the server graph 
lines should be almost right on top of the gps time graph.  If the GPS 
is wandering, these server lines will appear to move away from the GPS 
line over time.

http://dl.dropbox.com/u/9879631/peerstats%20after%20GSP%20power%20cycle%20with%20fudge%20factor%2020120316%202100.jpg

Here are the server lines in my ntp.conf for the GPS.

# windows lines for testing gps selected as main source - gpgga 9600 baud
server 127.127.20.5                 prefer minpoll 3 maxpoll 3 mode 18
fudge  127.127.20.5 time2 0.4260 refid GPS1

Note that the fudge time2 parameter required to get your GPS time 
comparable to internet server time will change if you change the baud 
rate of the GPS.

Sincerely,

Ron

> On the subject of accuracy, has anyone ever really looked at NTPD's offset
> filtering mechanism?  What it does now is sort the last (about 50) offsets
> from smallest to largest and then prunes the smallest or largest, depending
> on which is further away from the average, until there are only N (I forget
> what N is) offset observations left.
>
> There may be at least two problems with this filtering mechanism.  First,
> there is no apparent theory behind it; I have never seen such a crude filter
> that does not take into account any information inherent in the data.  On
> the other hand, what I don't know about filters would fill all 24 volumes of
> an encyclopedia.
>
> Second, we know that each offset observation should have arrived about one
> second after the previous one, yet NTPD does not take advantage of that
> knowledge.  There are filters, such as the Kalman filter that uses a
> Bayesian estimation approach to predict the next observation and adjusts it
> according to the prediction when it arrives, that do take advantage of
> previous observations.  Demonstrations of the Kalman filter on the Internet
> show almost spectacular results.  I used a Kalman filter in my clock
> simulation program and the results seemed pretty good.  However, there are
> numerical analysis considerations to programming a Kalman filter as the sums
> and products of observations can become large in a program that runs
> infinitely long.  Also, choosing the parameters of a Kalman filter is
> apparently a black art.
>
> Would it be worth it to recruit an electrical or systems engineer who
> claimed to know something about filtering data to take a serious look at
> NTPD's data filtering approach?  There has to be some reason that there is a
> significant negative correlation between delay and offset in NTPD.  There
> also has to be a reason that my GPS clock (BU-353, which, when it is working
> well, only has offset ±6 ms from zero) has a difference between about 0 and
> 47 ms from an NTP server on another computer that gets its time from 8 NTP
> stratum 2 servers over the Internet and has remarkably consistent offsets
> ±3.5 ms from zero.  The difference between the GPS clock and the average of
> the stratum 2 servers appears to be a function of the time of day; it is
> large during the mid-part of the day, when the Internet is busy and the
> delay is large and quite variable between servers, and small late in the day
> (right now it is -0.626; 6:55 PM EST), when the delay is smaller and pretty
> uniform for all stratum 2 servers.
>
> Charles Elliott
>
>    
>> -----Original Message-----
>> From: questions-bounces+elliott.ch=verizon.net at lists.ntp.org
>> [mailto:questions-bounces+elliott.ch=verizon.net at lists.ntp.org] On
>> Behalf Of Chris Albertson
>> Sent: Thursday, March 15, 2012 5:22 PM
>> To: unruh
>> Cc: questions at lists.ntp.org
>> Subject: Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock
>> error.
>>
>> On Thu, Mar 15, 2012 at 2:09 PM, unruh<unruh at invalid.ca>  wrote:
>>
>>      
>>> Unfortunately it is not that simple. That rate changes by significan
>>> amounts. Thus the rate you get after a week may be very different
>>>        
>> than
>>      
>>> the rate you get after an hour. That, I submit, is the chief obstacle
>>> to having an accurate clock. And that change in rate does not fit
>>>        
>> with
>>      
>>> the "Allan variance" assumptions (the noise source is not of the type
>>> assumed)
>>>        
>> You are right about that.  I was going to add in a bit about how to
>> pick the best time to look at the clock tower.  But left it out because
>> the point I was making was only that these things are not NTP
>> specific.   Details after that did not contribute the the main point.
>>
>>
>> Chris Albertson
>> Redondo Beach, California
>>      



-- 

(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such.  I don't always see new messages very quickly.  If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)

Ron Frazier
timekeepingdude AT c3energy.com



More information about the questions mailing list