Subject: Re: todr changes to improve clock accuracy across sleeps & reboots
To: Garrett D'Amore <garrett_damore@tadpole.com>
From: Perry E. Metzger <perry@piermont.com>
List: tech-kern
Date: 09/08/2006 11:22:17
Garrett D'Amore <garrett_damore@tadpole.com> writes:
> All that said, I don't mind waiting up to a second to get rid of the drift.

Neither do I, so we can quit discussing the side issues. :)

So lets just code. :)

In theory, ports might have battery clocks with higher precision than
one second, but I haven't encountered one, so on the KISS principle we
can ignore that issue until such a clock appears. (If one does appear,
a simple flag saying "don't spin" is probably enough because we'll get
decent microsecond or nanosecond data out from it without spinning.)

So, repeating the earlier proposal, we then just have some simple code
that spins in the inittodr case for an appropriate period, and some
simple code that sleeps-then-sets for the resettodr case. We're then
"good enough" for now, and if people want to do harder stuff later
they can.

So, getting quite practical for a moment, the question is, do we want
to do the inittodr spin in todr_gettime or in the MD code? I favor
doing it in MI code if at all possible, in which case todr_gettime is
probably the place.

On the todr_settime side, it should be pretty easy to set the sleep
until the next tick happens right in todr_settime.

BTW, as an aside, why is the /* simple sanity checks */ still in
todr_gettime rather than clock_ymdhms_to_secs? (Also, for that check,
keep in mind that particularly politically correct clocks could have
dt_sec hit 61 during leap seconds.)

Perry