Perry E. Metzger wrote:
> I discussed this in private mail with Garrett, and he thought I should
> bring it up here.
>
> 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.
>
> When you're walking about with your laptop and you sleep and wake the
> thing 10 times a day, the clock drifts quite a bit. This is because
> every time you wake your machine up (or reboot it), it sets the system
> clock via inittodr to the time read from the RTC chip, but that time
> might be up to one second off because we just read the time and set
> the system clock rather than waiting for the second to tick
> over.
>
> Furthermore, every time we sleep or shut down the system, we reset
> the RTC chip from the system clock, which can cause it to deviate by
> up to one second as well, because we are effectively truncating
> fractional seconds when this happens, rather than waiting until the
> fractional seconds hit zero again before doing the resettodr.
>   

The current code "rounds" usec here.  If usec >= 500000, then it rounds
secs up, else it truncates.  So it isn't quite as bad as "always
truncates".  But it isn't as good as waiting to change the time right
after the second, either.

> It would be nice if, optionally, one could wait up to one second,
> spinning, for the RTC chip to turn over a fresh second before doing
> inittodr. Similarly, one would, optionally, wait up to one second
> before doing the resettodr -- that could be done with an interval
> timer controlled sleep since the system clock has high precision.
>
> This is only needed on platforms where the precision of the battery
> backed clock has a one second granularity/precision, but sadly that
> seems to be most platforms.
>
> I suggested making this optional (and possibly sysctlable) because
> some people won't care and will resent the one second additional
> delay.
>   

I think making it tunable is unnecessary.  And we don't have to wait a
second every time, we just have to wait until the next second boundary
is seen.    So a second wait is the worst case.  It will on average be
about half that. :-)

As has been pointed out already, at least in the inittodr case we could,
in theory, sleep waiting for this to happen on a clock boundary.  The
only problem with doing that in MI code is that right now I am not
entirely confident that all the code which calls inittodr does so at
times when interrupts are enabled.

The other problem, is that during boot the normal boot when this occurs,
the kernel is still generally single threaded, and adding the necessary
code to parallelize this might be more effort than it is worth.

    -- Garrett

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