From owner-freebsd-questions@FreeBSD.ORG Fri Apr 23 15:13:49 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3817E16A4CE for ; Fri, 23 Apr 2004 15:13:49 -0700 (PDT) Received: from pd4mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1437343D1D for ; Fri, 23 Apr 2004 15:13:49 -0700 (PDT) (envelope-from flowers@users.sourceforge.net) Received: from pd5mr6so.prod.shaw.ca (pd5mr6so-qfe3.prod.shaw.ca [10.0.141.182]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0HWN0033B9R0P4@l-daemon> for freebsd-questions@freebsd.org; Fri, 23 Apr 2004 16:13:48 -0600 (MDT) Received: from pn2ml5so.prod.shaw.ca ([10.0.121.149]) by pd5mr6so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0HWN004KH9R26470@pd5mr6so.prod.shaw.ca> for freebsd-questions@freebsd.org; Fri, 23 Apr 2004 16:13:50 -0600 (MDT) Received: from sirius (S0106004001438e5b.cg.shawcable.net [68.144.47.89]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0HWN00HAQ9R0EL@l-daemon> for freebsd-questions@freebsd.org; Fri, 23 Apr 2004 16:13:48 -0600 (MDT) Date: Fri, 23 Apr 2004 16:13:44 -0600 From: Danny MacMillan In-reply-to: <20040423124118.GA20775@happy-idiot-talk.infracaninophile.co.uk> To: Matthew Seaman , hugle , freebsd-questions@freebsd.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-15; format=flowed Content-transfer-encoding: 7BIT User-Agent: Opera7.23/Win32 M2 build 3227 References: <159171051438.20040423090456@vkt.lt> <20040423121311.GB41702@munk.nu> <20040423124118.GA20775@happy-idiot-talk.infracaninophile.co.uk> Subject: Re: microuptime() went backwards X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2004 22:13:49 -0000 On Fri, 23 Apr 2004 13:41:18 +0100, Matthew Seaman wrote: > On Fri, Apr 23, 2004 at 01:13:11PM +0100, Jez Hancock wrote: >> On Fri, Apr 23, 2004 at 09:04:56AM +0300, hugle wrote: >> >> > SOmetimes I see such messages in dmesg. >> > >> > perl# dmesg >> > uptime() went backwards (1574174.333073 -> 1573478.944788) >> > >> > what they mean? and what causes them to appear ? >> > is it good or bad?? :) >> >> I'd always presumed these messages occured on my machine because the >> ntpd (network time protocol daemon) had adjusted the system clock. I >> can't actually tell you for sure since the messages aren't logged by >> syslog here so there's no easy way of comparing the times to see if they >> correspond to the ntpd adjustments. ntpd can be configured to maintain a log file and does, if I recall correctly, log a warning messages each time it is forced to step rather than slew the time (see below). >> Check to see if you have ntpd running - if so that's probably the reason >> for the messages. > > Actually, that shouldn't happen because of ntpd(8). If ntpd detects > that your system clock is fast, it will make it run slightly slower > until it gradually comes back into synch. It shouldn't ever jump the > system clock to the right time during normal operation, neither should > it ever cause the system clock to run backwards. A partial excerpt from man ntpd(8): -x Normally, the time is slewed if the offset is less than the step threshold, which is 128 ms by default, and stepped if above the threshold. This option forces the time to be slewed in all cases. If the step threshold is set to zero, all offsets are stepped, regardless of value and regardless of the -x option. In general, this is not a good idea, as it bypasses the clock state machine which is designed to cope with large time and frequency errors Note: Since the slew rate is limited to 0.5 ms/s, each second of adjustment requires an amortization interval of 2000 s. Thus, an adjustment of many seconds can take hours or days to amortize. This option can be used with the -q option. How NTP Operates ... As the result of this behavior, once the clock has been set, it very rarely strays more than 128 ms, even under extreme cases of network path congestion and jitter. Sometimes, in particular when ntpd is first started, the error might exceed 128 ms. This may on occasion cause the clock to be set backwards if the local clock time is more than 128 s in the future relative to the server. -Danny