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