On Jun 20, 2011, at 2:22 PM, Steve Tryon wrote: > The reason I ask about large corrections is a scenario that I saw with a > configuration that we originally tried. In essence, each server in the > cluster was configured the same: > - clients of 0.us.pool.ntp.org and 1.us.pool.ntp.org > - peers with all nodes in the cluster > - using local clock as stratum 10 source > > We saw some significant timewarps in our application and this is what we saw > in our ntp log file: > > May 29 04:59:20 sprint-ac-4 ntpd[12316]: synchronized to LOCAL(0), stratum 10 > May 29 05:07:57 sprint-ac-4 ntpd[12316]: synchronized to 192.43.244.18, > stratum 1 > May 29 05:09:58 sprint-ac-4 ntpd[12316]: synchronized to LOCAL(0), stratum 10 > May 29 05:27:05 sprint-ac-4 ntpd[12316]: synchronized to 192.43.244.18, > stratum 1 > May 29 06:12:23 sprint-ac-4 ntpd[12316]: time reset +28.770117 s > May 29 06:16:40 sprint-ac-4 ntpd[12316]: synchronized to X.Y.Z.203, stratum 12 > May 29 06:16:12 sprint-ac-4 ntpd[12316]: time reset -28.769913 s > May 29 06:20:31 sprint-ac-4 ntpd[12316]: synchronized to LOCAL(0), stratum 10
Yes, you were getting timewarps because you configured your undisciplined local clock as a potential time source, but it wasn't close to being in sync with real time. Just leave the local clock unconfigured, unless you actually do have some other timekeeping mechanism correcting it (ie, an ACTS modem, GPS, or similar), in which case you could just configure ntpd as a valid stratum-1 instead. ntpd understands what to do if it loses connectivity with it's upstream sources, and gradually increases the dispersion to indicate the potential timekeeping error so that clients can decide to prefer some other source which is doing better. Regards, -- -Chuck _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
