[ntp:questions] Problem facing with Ntp client Configuration

William Unruh unruh at invalid.ca
Fri Mar 28 00:46:06 UTC 2014

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. 

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