Richard Earnshaw <Richard.Earnshaw@buzzard.freeserve.co.uk> writes:
> On Thu, 07 Sep 2006 21:17:33 EDT, "Perry E. Metzger" wrote:
>> 
>> Richard Earnshaw <Richard.Earnshaw@buzzard.freeserve.co.uk> writes:
>> > Why not leave the setting of the system clock as is (if you aren't on 
>> > line, then clock precision to within a second is just fine); and when 
>> > shutting down, don't write the RTC if it is within (say) 1 second of the 
>> > current time.  This way you've preserved essentially all the accuracy of 
>> > your RTC without stalling at any point.
>> 
>> The system clock is often being conditioned by something like NTP. The
>> reason for writing back the RTC when a change in the system clock
>> happens or another event that triggers resettodr is to assure that
>> they stay in sync so the next reboot gets the benefit of whatever is
>> conditioning the clock.
>> 
>
> No, you miss my point.  There are two operating scenarios to consider:
>
> 1) The system is stand-alone, and there's no access to an external 
> reference clock.
>
> 2) The system is network attached and can use 'global' time (eg by syncing 
> with ntp).

You miss #3

3) As with my laptop, sometimes the box is connected to the network
   and has access to external references, and sometimes it is not, and
   there is no easy way to predict in advance what state you will be in.

> For case 1) we don't really care about accuracy of the clock to within a 
> second, we just care that we don't mess up the RTC by repeated sleeps and 
> reboots.
>
> For case 2) the RTC is pretty much irrelevant.  We'll get the real time 
> from NTP and the only use for the RTC is to estimate the time during boot 
> and to preserve the NTP derived time in case next time we restart we are 
> disconnected.

Consider #3 for a moment...

Perry