Perry E. Metzger wrote:
> 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.
>   

In case 3, ntp will correct the drift when you connect.  While
disconnected, if you did say 10 shutdowns/restarts a day, the worst case
drift is about 20 seconds.  I know of onboard RTCs that drift that much
per day anyway.   (Granted, that's pretty darn bad.)

But the point is, while you're disconnected you don't care about the 20
second drift.

When you reconnect, you'll run ntp, and get an accurate clock again.

All that said, I don't mind waiting up to a second to get rid of the drift.

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


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191