William Unruh wrote:
On 2014-03-27, David Lord <[email protected]> wrote:
William Unruh wrote:
On 2014-03-27, David Lord <[email protected]> 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.
David
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.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
