Subject: Re: todr changes to improve clock accuracy across sleeps &
To: Perry E. Metzger <>
From: Richard Earnshaw <>
List: tech-kern
Date: 09/08/2006 08:02:30
On Thu, 07 Sep 2006 21:17:33 EDT, "Perry E. Metzger" wrote:
> Richard Earnshaw <> 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).

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 

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 

So from the above, I contend that in case 1) we never want to adjust the 
RTC unless the user has explicitly set the clock.  For case 2) we don't 
really care about the RTC except when we're about to transition to case 1).

Hence my contention that we should only write the RTC at shutdown if it is 
materially different (> 1s, maybe even more), and at boot we don't really 
care about the RTC's precise time to within a second.

As a side issue, my experience of computer clocks (not the RTC) is that 
they are both notoriously unstable and inaccurate for the purposes of time 
keeping.  Maybe it would be better to have an NTP driver that could 
discipline the clock from the RTC (maybe like some PPS drivers do).