lkml.org 
[lkml]   [1999]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: updating the RTC automagically
On 22 Nov 99, at 17:22, Guest section DW wrote:

> 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.

I think you are becoming unfair here.

> It destroys good information.

You mean, it sets the RTC clock to the system time, destroying
information? It does if the system clock is synchronized to some
external time reference source. In that case the RTC is a slave
clock, not a master clock.

> 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.

I don't know whether this is true or why it is there, but I'm sure
it's not a problem of the kernel.

You are aware that the average quarz drifts by 2PPM per °C?

>
> 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.

Please think what you want if you set the system time.

>
> 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.

The question is which approach pollutes user programs most, not to
talk about portability.

>
> 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.

"calculate the actual time" is an interesting concept. Maybe you can
explain how it works, especially if a system is up several months. My
RTC drifts about a minute per week during summer...

Regards,
Ulrich


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.089 / U:0.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site