From owner-freebsd-questions@FreeBSD.ORG Tue Mar 4 19:19:08 2014 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB4E9786 for ; Tue, 4 Mar 2014 19:19:08 +0000 (UTC) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C0AF7C64 for ; Tue, 4 Mar 2014 19:19:08 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay3.apple.com ([17.128.113.83]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0N1X0019LEXDWCH1@mail-out.apple.com> for freebsd-questions@freebsd.org; Tue, 04 Mar 2014 11:18:39 -0800 (PST) X-AuditID: 11807153-f799f6d000001862-69-5316270f8b49 Received: from [17.149.226.114] (Unknown_Domain [17.149.226.114]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 59.D7.06242.F0726135; Tue, 04 Mar 2014 11:18:39 -0800 (PST) Subject: Re: ntp frequent time resets - battery dead? From: Charles Swiger In-reply-to: <201403040907.s2497MvI042115@mech-cluster241.men.bris.ac.uk> Date: Tue, 04 Mar 2014 11:18:39 -0800 Message-id: <339ED6B9-F04D-4812-B228-729696C64E47@mac.com> References: <201403040907.s2497MvI042115@mech-cluster241.men.bris.ac.uk> To: mexas@bris.ac.uk X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHLMWRmVeSWpSXmKPExsUiOPVRkS6/uliwQe8SLYuXXzexWNxdmOTA 5NG/eCaLx4xP81kCmKK4bFJSczLLUov07RK4MiasucNY0M5Xsf3ta8YGxgncXYycHBICJhJt T44wQthiEhfurWcDsYUE+pkk9lziBbGZBbQkbvx7ydTFyMHBK6Ansf2XHEhYWMBU4tCuJawg YTYBNYkJE3lAwpwCnhLbtu9jArFZBFQk7h67yAgxRVFiR9saFghbW2LZwtfMIDavgJXE371d UFs9JA49XwMWFxEQkWhed54N4jJZidPnnrNMYOSfheSgWQgHzUIydQEj8ypGgaLUnMRKY73E goKcVL3k/NxNjKBQaygM3sH4Z5nVIUYBDkYlHt4XHGLBQqyJZcWVuYcYJTiYlUR4TV+IBgvx piRWVqUW5ccXleakFh9ilOZgURLnXR8IlBJITyxJzU5NLUgtgskycXBKNTBW2jFu+Xlob+kH peJlLjuu5x8/1XMrIE43W2uVzp3tqumXZINzV3HVLbqa1SHg+mvjuTdfv7zasCm6eFHt9/NZ 9yQb3zGxut5tr/WxyPr3rOhG2T7zp3Fe8+vertur1rCHgan+qAHXvGrblvgL6XF5tsp9DG5n 3M4uOXJ6c8fB/dMzp/39IThdiaU4I9FQi7moOBEAy8KFKDECAAA= Cc: freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 19:19:08 -0000 Hi-- On Mar 4, 2014, at 1:07 AM, Anton Shterenlikht 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