Subject: Re: todr changes to improve clock accuracy across sleeps & reboots
To: Perry E. Metzger <perry@piermont.com>
From: Frank Kardel <kardel@netbsd.org>
List: tech-kern
Date: 09/09/2006 19:37:15
Perry E. Metzger wrote:

>David Laight <david@l8s.co.uk> 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 [1] 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
>>accuracy.
>>    
>>
>
>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.
>
>Perry
>  
>
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 
on exit.
Unless time_adjust is different from 0 we should refrain from disturbing the
rtc.

Must of the kernel fragments look like started but never completed 
projects :-(.

Frank