From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zimbra.somanetworks.com (gw-yyz1.somanetworks.com [216.126.67.39]) by bilbo.ozlabs.org (Postfix) with ESMTP id 45A49B7079 for ; Tue, 1 Sep 2009 12:20:03 +1000 (EST) Message-ID: <4A9C84D0.8040200@somanetworks.com> Date: Mon, 31 Aug 2009 22:20:00 -0400 From: Benjamin Gamsa MIME-Version: 1.0 To: Paul Mackerras Subject: Re: time jumps forward/backwards References: <4A9C465D.4010801@somanetworks.com> <19100.24755.889091.412993@cargo.ozlabs.ibm.com> <4A9C6446.2000202@somanetworks.com> <4A9C664D.6010504@somanetworks.com> In-Reply-To: <4A9C664D.6010504@somanetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: linuxppc-dev@lists.ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Benjamin Gamsa wrote: > Benjamin Gamsa wrote: >> Paul Mackerras wrote: >>> Ben Gamsa writes: >>> >>>> It appears to be the case that when the time on the system is around >>>> the epoch (1970), that time will occasionally jump forward and then >>>> backward by about 17592 seconds. When it jumps forward, it always >>>> jumps back a few milliseconds later. However, it's not always easy >>>> to catch these occurrences. The delta is more specifically about >>>> 17592186059 usec, give or take a few 10s of microseconds (most of >>>> the time), despite the fact that the user-level program I have that >>>> is testing it only checks every 10 milliseconds. >>> >>> I don't think the time code in the kernel is designed to handle >>> negative values, i.e., times before the epoch. If you want it to do >>> that you'll have to check places like arch/powerpc/kernel/time.c, >>> kernel/time/timekeeping.c, arch/powerpc/include/asm/time.h, etc., and >>> make sure that it uses signed types where necessary and that the >>> arithmetic is correct. >>> >> >> The time never goes negative. It starts off at the epoch and moves >> forward, but sometimes it jumps forward by 17952 seconds, and then >> immediately jumps back. But it never goes negative (or prior to 1970). >> > > One important thing I forgot to add is that ntpd is running on this > system, but the ntp servers are not available. I suspect the problem > may be related to ntpd, even though I've seen the time jump even when I > had ntpd stopped within gdb. I've not yet been able to confirm if the > problem still occurs when ntpd is never even started, although I will be > testing that soon (the tests often require many hours to establish if > there are no jumps). For what it's worth, the problem occurs even when ntp is not even started. ben