[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ntp-bugs
Subject:    Re: [ntp:bugs] Odd NTP behaviour.
From:       "David L. Mills" <mills () udel ! edu>
Date:       2002-01-16 16:14:55
[Download RAW message or body]

Ulrich,

This is a matter of statistics, not a matter of what you or I choose to
believe in our fantasies. If you are going to make a decision whether or
source is believable or rechable in a few minutes, then the sampling
frequency for all mitigants must be commensurate. Period and game over.

Dave

Ulrich Windl wrote:
> 
> Dave,
> 
> thanks for the lengthy explanation (that I partially stripped in this
> reply). Still I have a different opinion as typed in below:
> 
> On 15 Jan 2002, at 19:29, David L. Mills wrote:
> 
> > Why, you say, shouldn't the poll interval for the remote NTP source be
> > allowed to increase if not selected to discipline the clock? Very bad
> > idea, as confirmed in simulation. The problem is, if you want the
> > selection algorithm to detect falseticking reference sources, as does
> > happen occasionally (TrueTime), you really need to give the algorithm a
> > balanced set of samples, not a radio every minute and a remote source
> > every fifteen radio minutes. You need to compare both in the same round
> > of each volley.
> 
> Assuming you (NTP)= can compact the values in the filter stahes to a
> useful tuple of values, the actual polling interval does not matter as
> long as you have such a tuple of values for each source at any time IF
> the tuple of values is able to describe the quality of the source.
> 
> Now I wonder if a tuple consisting of (jitter, offset, wander,
> frequency error) is enough to feed the clock selection algorithm (and
> combination algorithm later on). Naively I assume that the values shown
> for "ntpq -c rl" that describe the quality of the local clock should
> also be sufficient to describe any other time source.
> 
> Did I make a fundamental mistake here, or did you just decide to do it
> in a different way?
> 
> Regards,
> Ulrich
[prev in list] [next in list] [prev in thread] [next in thread]