In article <[EMAIL PROTECTED]>, lmr <[EMAIL PROTECTED]> wrote: > Is xntpd configurable to reconnect if the connection fails?
xntpd is either seriously obsolete or misnamed. No version of ntpd uses connection oriented protocols, so there are no connections to fail. See the very recent thread about using TCP. "The" implies a single server; that is not a recommended configuration. > What happens to the OS time when the connection fails? When ntpd has not received successful replies, or broadcasts for an extended period of time, the time will coast at its best available estimate of one second per second. It will also stop serving time to downstream ntpds. Over shorter intervals additional adjustments may still be in progress to reflect recent replies. > How can an application know if the connection has failed? There is no connection, so the following is about recognizing extended periods with no time synchronisation. Depends on the OS. If you have the kernel time discipline, which would require that xntpd be misnamed, you should have a utility called adjtimex, although it also goes by other names, which can tell you the current estimated and worst case error bounds on the time; it's up to you to decide what is an acceptable error bound. Otherwise you can use the ntpd management protocols, either directly or using ntpq or ntpd (or whatever they are misnamed as) to read the state of ntpd. > What does ntp_gettime returns if the connection has failed? Which OS. There seems to be one in Slackware 11 libc, but I can't find any documentation on my machine. I suspect, on that system, it is a front to the same system call as used by adjtimex and will tell you the error estimates. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
