Subject: Re: ntpq regression (?)
To: Jukka Salmi <j+nbsd@2006.salmi.ch>
From: Frank Kardel <kardel@ntp.org>
List: current-users
Date: 06/18/2006 18:11:05
Jukka Salmi wrote:

>Jukka Salmi --> current-users (2006-06-15 20:56:32 +0200):
>
>>Hi,
>>
>>since upgrading ntpd (from 4.2.0-r to 4.2.2-o) `ntpq -pn' reports:
>>
>>$ ntpq -pn
>>     remote           refid      st t when poll reach   delay   offset  jitter
>>==============================================================================
>>#212.254.26.76   213.144.132.251  3 u   26   64  377    0.204   87.820  10.383
>> 212.254.26.75   212.254.26.76    4 u   11   64  377    0.226   83.891   7.109
>>
>>The `selected' peer ('#') used to be a `sys.peer' ('*'), and the
>>`reject' peer (' ') used to be a `candidat' ('+').
>>
>
>After restarting ntpd I see
>
>$ ntpq -pn
>     remote           refid      st t when poll reach   delay   offset  jitter
>==============================================================================
>*212.254.26.76   195.216.80.207   3 u    1   64   37    0.206    0.129   7.519
>+212.254.26.75   212.254.26.76    4 u    1   64   37    0.184   -2.813   5.601
>
>However, after the next ntpd restart `ntpq -pn' output was again as
>reported in the first post...
>
>
>Regards, Jukka
>
>
This is not an ntpq regression but a visible effect of the minsane 
configuration
option. The default distributed in NetBSD is 2. That means at least 2 
sources
must be configured (and be usable and be close to each other).
But this is not suffcient because several tests are performed that can 
remove the
sources from the selection list before the minsane limit is checked.
Checks are for synchronisation status, stratum, synchronisation 
distance, loop, reachability,
falseticker detection.
Given the data above (with the #) the falseticker detection probably had 
its veto here.
Then we are left with one 'usable' peer for the remaining algorithms. 
Thus not a chance
for synchronisation to succeed. With this configuration it'll only work 
if the two peers are
sufficiently close to each other (see the example above).

So we are looking at a problematic configuration (possibly by default 
values) here.
This configuration will only work when both sources are usable and agree 
with each other.

There are two ways to fix this:
1) comment out "tos minsane 2" or set it to one (ntp default for 
historical reasons to allow
   backward compatibility and faster synchronisation but vales below 4 
disable byzantine agreement
   functionality.
2) set "tos minsane 4 (or greater)" for working byzantine agreement and 
configure *at least*
   that number of synchronisation sources.

I agree that "tos minsane 2" can be very confusing especially when there 
is no hint on how many
sync sources to configure.

Cheers,
  Frank