Date: Tue, 04 Mar 2014 11:18:39 -0800 From: Charles Swiger <cswiger@mac.com> To: mexas@bris.ac.uk Cc: freebsd-questions@freebsd.org Subject: Re: ntp frequent time resets - battery dead? Message-ID: <339ED6B9-F04D-4812-B228-729696C64E47@mac.com> In-Reply-To: <201403040907.s2497MvI042115@mech-cluster241.men.bris.ac.uk> References: <201403040907.s2497MvI042115@mech-cluster241.men.bris.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi-- On Mar 4, 2014, at 1:07 AM, Anton Shterenlikht <mexas@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?339ED6B9-F04D-4812-B228-729696C64E47>