Charles,

This is a PS to my preceding reply to this. If this makes no sense, read my other reply first.

Once you get your graphs working, you can select different IP's on the peerstats screen as follows. This may change in future updates to the program.

Right click on the graph.

An IP selection screen pops up.

To select a few IP's to show:

     a) click the check boxes for just the IP's you want
     b) click OK

To select all but a few IP's to show:

     a) click the all button
     b) click the check boxes to unselect the IP's you don't want
     c) click OK

To get back to the full list of IP's

     a) right click to bring up the IP selection screen
     b) click none   (Think of it as filtering none of them.)
     c) click OK

There was something else I wanted to mention, and I'm sure I'll remember it shortly after sending this. Anyway, good luck.

Sincerely,

Ron



On 3/16/2012 7:07 PM, Charles Elliott wrote:
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

Reply via email to