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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
