[19572] in Athena Bugs
Jonathon Weiss: sun4 [9.0.8]: ntpd
daemon@ATHENA.MIT.EDU (Jonathon Weiss)
Thu Aug 9 04:39:51 2001
Message-Id: <200108090839.EAA01920@bearing-an-hourglass.mit.edu>
From: Jonathon Weiss <jweiss@MIT.EDU>
To: bugs@MIT.EDU
Date: Thu, 09 Aug 2001 04:39:44 -0400
This problem seems to remain in the public release of 9.0 (though it
is probably unrelated to the bug Angie just reported.) It's worth
noting that if I kill off ntpd entirely I see something like 80 'afs:
adjusting clock' messages a day. Indicating that the clock is doing
something sufficiently stupid that ntpd can't correct for it without
stepping the clock. Maybe we're dropping clock interrupts on the
floor? I wonder if the Cisco packetbuster(tm) will clean those up...
------- Forwarded Message
Date: Tue, 26 Jun 2001 23:03:15 -0400 (EDT)
Message-Id: <200106270303.XAA01141@the-other-woman.mit.edu>
To: testers@mit.edu
CC: jweiss@mit.edu
Subject: sun4 [9.0.8]: ntpd
From: Jonathon Weiss <jweiss@MIT.EDU>
System name: the-other-woman.mit.edu
Type and version: Sun-Blade-100 9.0.8 (with mkserv)
Display type: m64, gfxp, ifb
Shell: /bin/athena/tcsh (/usr/local/bin/sipbtcsh?)
Window manager: /usr/local/bin/vtwm.gamma
What were you trying to do?
Look at my syslogs
What went wrong?
According to them, every 16 minutes ntpd loses sync and steps the time
What should have happened?
ntpd shouldn't have to step the time
Yo, got any documentation, or other info?
yeah, the sunblade in the test cluster is doing this too Also,
on both machines /var/athena/ntp.drift contains 500.000, which
seems suspicious. Is it possible that we're having some weird
interaction between the clock rate and ntpd or something?
------- End of Forwarded Message
