Subject: Re: [RFC][PATCH] new timeofday core subsystem (v. A2)
From: john stultz <johnstul@us.ibm.com>
To: Tim Bird <tim.bird@am.sony.com>
Cc: Nigel Cunningham <ncunningham@linuxmail.org>,
       lkml <linux-kernel@vger.kernel.org>
In-Reply-To: <4200316C.2080709@am.sony.com>
References: <1106607089.30884.10.camel@cog.beaverton.ibm.com>
	 <41FFFD4F.9050900@am.sony.com>
	 <1107298089.2040.184.camel@cog.beaverton.ibm.com>
	 <4200166A.6050309@am.sony.com>
	 <1107303548.2040.204.camel@cog.beaverton.ibm.com>
	 <4200316C.2080709@am.sony.com>
Content-Type: text/plain
Date: Tue, 01 Feb 2005 18:00:16 -0800
Message-Id: <1107309617.2040.227.camel@cog.beaverton.ibm.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1679
Lines: 40

On Tue, 2005-02-01 at 17:48 -0800, Tim Bird wrote:
> john stultz wrote:
> > Interesting patch. Indeed, the trade off is just how quickly you want to
> > boot vs how much drift you gain each suspend/resume cycle. Assuming all
> > of the clocks are good, your patch could introduce up to 2 seconds of
> > drift each suspend/resume cycle. 
> 
> If we're not writing to the RTC on suspend, then I believe the drift is
> capped.  For some consumer products, 2 seconds of drift is OK.
> 
> Nigel, does the RTC get written to, or just read, on suspend?

I'll let Nigel respond, but I don't believe so. The time code only
writes out to the CMOS every X-minutes if we're synced w/ the NTP
server.

> Also, I'm worried about the clock appearing to run backwards over a suspend.
> Unless a suspend/resume cycle took less than 1 second, I don't think this could
> happen.  Is that right?

Well (with my code, the existing code might be slightly different), on
suspend we read the persistent clock and we accumulate all the time that
has passed on the timesource. Then on resume we read the persistent
clock, the delta between persistent clock reads (which cannot be
negative unless the CMOS runs backwards) is added to the system time and
a new time interval is started from the current value of the
timesource. 

So, unless something tweaks the CMOS between reads, or the hardware has
problems, then time should not go backwards.

thanks
-john


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/