Subject: Re: todr changes to improve clock accuracy across sleeps & reboots
To: Perry E. Metzger <email@example.com>
From: Frank Kardel <firstname.lastname@example.org>
Date: 09/09/2006 19:37:15
Perry E. Metzger wrote:
>David Laight <email@example.com> writes:
>>On Thu, Sep 07, 2006 at 11:04:31AM -0400, Perry E. Metzger wrote:
>>>Most of the battery backed up RTC chips in use have very coarse
>>>precision compared to the kernel. That is, they read out only to the
>>>nearest 1 second. They often have quite good accuracy, however.
>>Some of them also have 'trim' registers that can be set to improve
>>the long term accuracy. So if the time is corrected, and you
>>remembered when it was last corrected, some simple maths  gives
>>an update for the trim register.
>I was wondering about that. Garrett recently removed all our (unused)
>hook based support for updating the trim registers -- maybe we should
>bring that back.
>>The current situation for systems not using NTP is stupid, we rewrite
>>the time from a low-quality uncalibrated source (the system clock)
>>over that of a device that is meant to have reasonable long term
>Perhaps it would be best if we only wrote back the system clock to the
>battery clock if the system clock knows it is being NTP conditioned,
>and otherwise conditioned the system clock based on the battery clock.
That knowledge is already there...
The int variable time_adjusted gets or'ed with 0x1 when adjusttime with an
effective adjustment is called. 0x2 is or'ed into it when ntp_adjusttime is
called in a time-adjusting manner. Maybe we should or in 0x4 when we
do a set-time and use the information to decide whether to set the rtc
Unless time_adjust is different from 0 we should refrain from disturbing the
Must of the kernel fragments look like started but never completed