Re: [RFC][PATCH] new timeofday core subsystem (v. A2)

[Nigel Cunningham <ncunningham@linuxmail.org>]

Hi.

On Wed, 2005-02-02 at 13:00, john stultz wrote:
> 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.

Yes, just read.

> > 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.

Sounds good.

Regards,

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com

Ph: +61 (2) 6292 8028      Mob: +61 (417) 100 574