SivaKumar Subramani wrote:
I've found some problem in xntpd . I would like to know under which scenario the poll value reach to 1024, during this time the offset value set to too large. Due to this the system clock is not set properly. How to avoid or correct this behavior???I've copied the output of the ntpq peers command and the content of the ntp.conf file. ntpq -p remote refid st t when poll reach delay offset disp ============================================================================== 143.209.150.72 128.252.19.1 2 u 477 1024 377 399.89 -194866 15890.6 143.209.150.232 143.209.150.72 3 u 508 1024 377 399.69 -193036 15890.6 143.209.133.66 143.209.150.72 3 u 482 1024 377 399.75 -194566 15890.6 ntp.conf server 143.209.150.72 prefer server 143.209.150.232 server 143.209.133.66 Thanks in advance. -Sivakumar _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
Anything called "xntpd" is several years out of date!! Upgrade! (Sun and other vendors are still distributing a very old version: V3-5.93e which was released around 1998!) The current version of the software is ntpd v4.2.0. There is a 4.2.1 "release candidate" available for beta testing.
Your ntpd output indicates what appears to be an extremely poor choice of servers, an extremely poor network connection or both! The potential error in transferring time from server to client is 1/2 the round trip delay or over 200 milliseconds in your case. The dispersion figures (some sort off "noise" measurement) are extremely high (something below 10 would be good). Finally, the offset figures suggest that your clock is in error by more than two days if the value is in seconds. If it's in milliseconds, it's still far to large!! Ntpd or xntpd cannot correct an error greater than 1024 seconds (about 17 minutes).
Set your clock as close as possible to the correct time before starting ntpd. With your version of xntpd, your can use ntpdate to set the clock or you can use "date" or whatever command your O/S provides for setting the clock.
Choose servers close to you in net space (low delay: MUCH lower than 400 milliseconds). If your network connection rather than the choice of servers is your problem, try to get a better one. 400 milliseconds is long enough to send a signal around the equator at least three times!!!!
_______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
