[EMAIL PROTECTED] (Rob Neal) writes: >On Tue, 16 Sep 2008, Kevin Oberman wrote:
>> We have a fairly large "mesh" of NTP servers spread across the >> US. Almost all have PPS reference clocks and are quite >> accurate. Recently one of the reference clocks located across the county >> seems to have failed. Such is life. >> >> The problem is that the system's time started drifting and eventually >> became far enough out of sync with the mesh to be marked as a bad >> ticker. >> >> The only way I could get the clock to slew or step the time was to edit >> the configuration and comment out the reference clock and PPS. It looks >> like the system will only use the time from a reference clock when and if >> the clock is configured, even if it can't be read. >> >> Is there any way to "fix" this? > What is it that you consider broken? Please clarify. > I've re-read this several times, and don't see the problem. > A reference clock broke. It was disregarded because it chimed > badly. > You expected something different? A hardware clock broke. The computer which was using that hardware clock insisted on using that hardware clock even though it gave no time. It acted as a server, and eventually its time drifted so badly everyone else saw it as a bad chimer. It seems to have had other server lines in the /etc/ntp.conf, but ignored them in favour of a non-working refclock. That is how I interpret what he said, but I may be wrong as well. > A clock must be configured to be used, yes. Sad but true. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
