In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > Anyway, I'm happy with keeping my machines within say 1/4 seconds of > UTC, considering that for many years the the company network
You need to do better than that if you want to avoid time steps, as ntpd will step if the local clock apears to differ from the estimated time from the servers by more than one eighth of a second, for a significant amouunt of time (about 15 minutes). A quarter second delay only results in a worst case eighth second error, and then only if it is possible for transmission in one direction to have no effective delay. > not sure what to check for, will the asterisk always disappear after a > problem? It should never disappear (except during a time step), as your local clock will never fail, which is one of the reasons why you should think whether you really need the local clock driver; the local clock driver prevents the time being marked invalid when you lose real servers. It will move, so you could check for no asterisk or asterisk on the local clock line. I think a more reliable test would be to monitor the stratum. ntpd also has a trap reporting mechanism, but I don't know of any standard trap receiver for ntpd and you will still have the problem of inferring the failure as the local clock will prevent ntpd detecting it as a failure. > If so, I would just check for presence of the string: > "*203.117.180.36" (it's my government's public time server) But you lose a lot of the benefit of your fallback servers. _______________________________________________ questions mailing list [EMAIL PROTECTED] https://lists.ntp.isc.org/mailman/listinfo/questions
