[ntp:questions] Problem facing with Ntp client Configuration

David Lord snews at lordynet.org
Fri Mar 28 11:26:41 UTC 2014

William Unruh wrote:
> On 2014-03-27, David Lord <snews at lordynet.org> wrote:
>> William Unruh wrote:
>>> On 2014-03-27, David Lord <snews at lordynet.org> wrote:
>>>> Biswajit Panigrahi wrote:
>>>>> Hi Mayer,
>>>>> I have done the required changes. I have found one problem regarding condition field in ntpq
>>>>> When ever I have restarted ntpd on client and executed ntpq "as"
>>>>> atcafs-n11s2:~# ntpq
>>>>> ntpq> as
>>>>> ind assid status  conf reach auth condition  last_event cnt
>>>>> ===========================================================
>>>>>   1 45503  9044   yes   yes  none    reject   reachable  4
>>>>> Condition field shows "reject" for more then 15 to 20 minute then after it changes to "sys.peer" after then only sync happens.
>>>>> I have opened the port 123 for ntp. Still it shows reject 
>>>>> Please let me know reason for this to fix the issue
>>>> Why do you believe there is an issue to be fixed?
>>>> Ntpd takes a certain amount of time to sync after a restart.
>>>> You could add a few more ntp sources. Three sources are not
>>>> enough, four is good, five is safer.
>>> Why not 4397523 servers? Even better. 
>> Why not read up on what ntpd does and cannot do?
>> I'm sure you knew the answer before you posted that?
> Yes. Argument through hyperbole. 
> There is an argument for more than 1 sever, but you should recognize
> what that argument is. Three are more than enough(that guards against
> one going crazy.) If you really think that there is chance that more
> than one will go crazy 5 is good, but if there is resonable chance of 2
> going crazy, then the probabilities become high that more than 2 will as
> well, at which point you enter an arena of dimishing returns. You need
> to fix your sources, not rely on more and more servers. So, one is fine,
> recognizing that there is no way of noticing if that one goes crazy. Two
> are no better than one, and have the danger of hopping from one to the
> other if one goes crazy, so three is a protection against one going
> crazy. If it is more than that, you have problems that needs a human to
> fix. It is true that hard disks have almost half of the bits being
> parity bits, but they also impliment a rather more sophisticated error
> identification and correction algorithm than does ntpd. 

The docs on intersection give an example of when three sources
is not enough and that is why I picked five. One of my servers
currently has an unreachable source so it's still able to make
a selection. It's not unknown that I lose two sources in  which
case that server will get kicked out of the pool rotation.


> And if one of your sources is going crazy, ntpd should send you a
> message to that effect so you can fix it, or use a different server. 
>> bye
>> David
>>> Use 1 if you want. The problem is, what if that one goes down or goes
>>> crazy. If it is yours fix it. If not, use another. 3 guards against one
>>> going crazy. As you up the numbers you guard against more and more going
>>> crazy. But since the probability of one going crazy is low, you may just
>>> decide to live with it. 
>>>> One of my servers, ntp-dev 4.2.7p433, was restarted on Mar 15:
>>>> time   remote  st  reach   offset
>>>> 18:36  oPPS     0    377   -0.001
>>>> reboot
>>>> 18:42   PPS     0      0    0.000
>>>> 18:48  oPPS     0     37  -60.233
>>>> 18:54  oPPS     0    377   -0.004
>>>> 19:00  oPPS     0    377   -0.001
>>>> Other servers without pps take a few minutes longer to sync.
>>> It depends on the poll interval. pps has a 16 second poll interval. Most
>>> others have a 64 sec initial poll interval, simply so as to not put to
>>> much stress on the server. If it is your own server you can stress it
>>> all you are comfortable with. 

More information about the questions mailing list