Subject: Re: todr changes to improve clock accuracy across sleeps &
To: Perry E. Metzger <firstname.lastname@example.org>
From: Richard Earnshaw <Richard.Earnshaw@buzzard.freeserve.co.uk>
Date: 09/08/2006 08:02:30
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
2) The system is network attached and can use 'global' time (eg by syncing
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).