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....@lists.ntp.org
[mailto:questions-bounces+elliott.ch=verizon....@lists.ntp.org] On
Behalf Of Chris Albertson
Sent: Thursday, March 15, 2012 5:22 PM
To: unruh
Cc: questions@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<un...@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
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
