> For my purposes, the "every 11 minutes" behaviour is great: I run NTP,
> and it gets in sync a few minutes after boot (Just a few hundred ms
> drift since last write to CMOS).
>
> I agree that for people wanting more accuracy, it needs to go. How
> about allowing someone like that to turn off the "write cmos every 11
> minutes:" behaviour?
>
> Roger.
But you see - the "every 11 minutes" behaviour is a loss for everybody.
It destroys good information.
You are happy, but with hwclock or some variation you would be in sync
faster and with greater accuracy.
As the hwclock manpage says:
If your system runs with 11 minute mode on, don't use
hwclock --adjust or hwclock --hctosys. You'll just make a
mess.
The present situation is that we have the system call adjtimex
with a strange peculiar undocumented side effect that nobody wants
namely that not only the system time is adjusted, but that the
kernel comes into a mode where it periodically overwrites RTC
with system clock.
This is not a clean design. It might be reasonable to have a system call
or ioctl "write system clock into RTC now". (Not that anybody who
cares about precise timekeeping would ever use it.) But today we
have this terrible combination where setting the system clock from
an outside source automatically leads to fumbling the RTC, making the
information accumulated in /etc/adjtime worthless.
There is only one right behaviour regarding the RTC: leave it alone
and write down how much it differed from real time at a given point
in time, and what the daily drift is. Then at boot time you read RTC,
calculate the actual time and set system time from that.
Andries
__
5:12pm up 1014 days, 6:02, 8 users, load average: 1.33, 1.08, 1.02
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/