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?
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