Re: Scary bugs

[Martijn van Oosterhout <kleptog@cupid.suninternet.com>]

Henrique M Holschuh wrote:

> The hwclock man page makes it very clear that if, for example, you have NTP
> running in your machine (implies "11 minute mode" for the kernel), you must
> *never* call --hctosys or --adjust, and shouldn't even call hwclock
> --systohc as that disables 11 minute mode. This isn't documented in the
> README.Debian of either ntp or util-linux.

Hmm, I've seen this mentioned in various places but have never observed
it.
I run a simple NTP server locally and the CMOS does still drift.

> Here's a possible (and probably broken somewhere :-) ) strategy to do this.
> It is not implementation-complete. For example, one would need to invalidate
> the drift file, as well as implement the idea of a drift file that only has
> the systematic drift stored, but not when it was last applied (I guess, I
> didn't study the hwclock code).

Gosh. Have you evver installed adjtimex? Have you looked at the --log
command?

> 1. Train hwclock so that it learns the RTC's drift without tampering. I'll
>    call this a "training period" where the user is strongly advised (in a
>    bothersome, impossible not to notice way) not to touch the RTC, and told
>    to deal with the crap himself if he does change the RTC.
> 
> 2. The RTC drift is reasonably constant (otherwise the RTC is useless).
> 
>    hwclock should refuse to change the RTC drift too much unless in training
>    mode. How much is 'too much' must be found by some careful testing, and
>    should probably be configurable.
> 
>    If the drift is too big, warn the user and do not change the sistematic
>    drift in the drift file.
> 
> 3. hwclock should refuse to run --adjust if the drift to be applied to the
>    RTC is "too big" (quite likely after a few days of downtime), warn the
>    user that the clock has gained/lost too many seconds/hours/days (just
>    like Solaris does), and maybe request the user to verify and run
>    something like hwclock --adjust --force-adjust; hwclock --hctosys
>    manually.

Here is an example of an adjtimex --log being run out of cron. Then
adjtimex -r produces:

hecate root/~>adjtimex -r |tail -5
least-squares solution:
  cmos_error = -8.41455 +- 0.00008 ppm      suggested adjustment =
0.7270 sec/day
   sys_error = -13.07469 +- 0.00007 ppm      suggested tick = 10000 
freq = 856863
note: clock variations and unstated data errors may mean that the
least squares solution has a bigger uncertainty than estimated here

There were a lot of measurements to get this result. It's quite accurate
now.

Martijn