[ntp:questions] Odd (mis)behavior when reference clock fails
oberman at es.net
Fri Sep 19 15:16:18 UTC 2008
The gateway chokes on signed mail and all of my mail is signed. As a
result, I guess none of my messages will ever make it to the news
I'm going to TRY to get my mailer to not sign this, but it may not make
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
> From: David Woolley <david at ex.djwhome.demon.co.uk.invalid>
> Date: Fri, 19 Sep 2008 08:08:38 +0100
> Sender: questions-bounces+oberman=es.net at lists.ntp.org
> Firstly, the original of this thread root has been demimed out of
> existence by the mail to news gateway. I thought the official line is
> that what went out to the mailing list was the same that which went to
> the newsgroup.
> All that remains is:
> > [demime 1.01d removed an attachment of type multipart/signed]
> This can be confirmed on Google groups.
> Rob Neal wrote:
> > 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.
> That should not be the case. Are you sure that the clock had stopped
> responding and stopped providing a PPS signal? If it is still providing
> PPS this will be used, and other clocks only to resolve the second
> Another thing to check of is whether there was a local clock configured.
> This can compromise fault recovery.
> What we really need is the contents of the configuration file and the
> result of running ntpq peers. We may then ask you for the result of
> running ntpq rv on the system and on each of its associations.
> Please reply in plain text, or directly to the newsgroup, otherwise
> neither I nor the originator of NTP will see your reply.
> questions mailing list
> questions at lists.ntp.org
More information about the questions