ntp frequent time resets - battery dead?

[Charles Swiger]

Hi--

On Mar 4, 2014, at 1:07 AM, Anton Shterenlikht <mexas at bris.ac.uk> wrote:
> I see in /var/log/messages:
> 
> Mar  4 00:16:40 mech-anton240 ntpd[764]: time reset +0.291030 s
> Mar  4 00:38:02 mech-anton240 ntpd[764]: time reset +0.344745 s
> Mar  4 00:57:37 mech-anton240 ntpd[764]: time reset +0.338739 s
> Mar  4 01:19:45 mech-anton240 ntpd[764]: time reset +0.355020 s
> Mar  4 01:41:34 mech-anton240 ntpd[764]: time reset +0.365177 s
> Mar  4 01:58:41 mech-anton240 ntpd[764]: time reset +0.306982 s
> 
> and so on.
> 
> The correction seems large to me.

Yes, it looks to be about ~1 second per hour.  That's 1:1000 ratio,
which is getting close to the typical kernel limit on adjtime().

Tweaking the step threshold might help.  Or look into tickadj / ntptime.

> Does this indicate that the battery is dead?

A dead battery usually means that the system won't keep the ToY clock updated
if the system is off and unplugged.  A PC would indicate BIOS checksum errors
and reset the ToY clock back to epoch.  I think Suns of that era were still
using OpenFirmware on EEPROMS which didn't need power to keep their settings.

> This is on a Sun Blade 1500 silver desktop, about 10 years old.

Having the clock run slow (ie, needing the time to be moved forwards) can
result from interrupt handling issues; if something like a USB controller, or
storage controller, etc is wonky and generating thousands of interrupts per
second, the ISR being busy might cause clock interrupts to be lost because
the kernel is otherwise busy.

That ought to be more common on commodity Intel hardware than on SPARCs; as the
SPARC v8 and later had several levels of nested interrupt contexts available, IIRC.

Regards,
-- 
-Chuck