Subject: todr changes to improve clock accuracy across sleeps & reboots
To: None <tech-kern@netbsd.org>
From: Perry E. Metzger <perry@piermont.com>
List: tech-kern
Date: 09/07/2006 11:04:31
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.

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.

Perry