Messages in this thread | | | Date | Mon, 22 Nov 1999 17:22:16 +0100 | From | Guest section DW <> | Subject | Re: updating the RTC automagically |
| |
On Mon, Nov 22, 1999 at 03:36:36PM +0100, Rogier Wolff wrote:
> 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/
| |