[ntp:questions] Rejecting Good Peers

Cal Webster cwebster at ec.rr.com
Wed Dec 3 15:31:18 UTC 2008


On Wed, 2008-12-03 at 09:46 -0500, Steve Kostecke wrote:
> Calvin Webster said:
> 
> >On Wed, 2008-12-03 at 02:25 +0000, Steve Kostecke wrote:
> >> On 2008-12-03, cwebster at ec.rr.com <cwebster at ec.rr.com> wrote:
> >> 
> >> > That still doesn't make sense to me. A peer is objecting to his peer
> >> > using a fellow peer as a candidate? Why then does this behavior only
> >> > present itself on the version 4.2.4 peer and none of the others?
> >> 
> >> The difference between 4.2.4 and 4.2.0 is greater than one might be led
> >> to believe.
> >
> >So this is *not* a normal function of peer relationships but an anomaly
> >caused by mixing different versions of NTP, right?
> 
> No.
> 
> v4.2.4 is properly detecting (and rejecting) a peer loop. v4.2.0 is not.
> 
> The NTP version numbers are not the major.minor.point that most people
> expect. Rather they are protocol_version.major.minor with an added 'pN'
> for point releases.
> 
> So the difference between 4.2.4 and 4.2.0 is more than a couple of point
> releases. It is, in fact, 2 entire development cycles.

Okay, I understand your version/release convention now. However, I guess
I'm a little thick-headed on the "peer loop" issue.

Please explain what a "peer loop" is or point me to the doc page that
explains it. I don't see the disadvantage of having common peers.

So, the new behavior is to select no candidates if they have common
peers? This would seem counter-intuitive from a reliability/redundancy
standpoint. What will this ver 4.2.4 server do when it can no longer
reach the master server? My guess is that it will either stop serving
time or die since it has no other reference (local undisciplined clocks
not configured). If true, this is an undesirable condition, and seems
especially wasteful when there are other time sources available even if
they may not be as precise as the master.

I'm sure I'm misunderstanding something here. Thanks for being patient
with me.





More information about the questions mailing list