linux-mips
[Top] [All Lists]

Re: Updating RTC with date command

To: linux-mips@linux-mips.org
Subject: Re: Updating RTC with date command
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
Date: Tue, 19 Jul 2005 17:20:08 +0200
In-reply-to: <Pine.LNX.4.61L.0507191555360.10363@blysk.ds.pg.gda.pl>
Mail-followup-to: linux-mips@linux-mips.org
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <CBD77117272E1249BFDC21E33D555FDC06018D@dbde01.ent.ti.com> <20050719143110.GD3108@linux-mips.org> <20050719144230.GE20065@lug-owl.de> <Pine.LNX.4.61L.0507191555360.10363@blysk.ds.pg.gda.pl>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.9i
On Tue, 2005-07-19 16:06:21 +0100, Maciej W. Rozycki <macro@linux-mips.org> 
wrote:
> On Tue, 19 Jul 2005, Jan-Benedict Glaw wrote:
> 
> > hwclock is the userspace utility to manually once set the time. In
> > normal operation, this should only be called _once_, after the system is
> > switched on for the very first time.
> 
>  Well, `hwclock' should normally be used to update the RTC every time 
> after a manual system clock update.

Which of course should only be done once. Ever :)

> > During lifetime, ntpd should execute and thus the system's current time
> > will be written to the HW clock every now and then. Additionally, most
> 
>  Note that ntpd only updates minutes and seconds and then only if the 
> difference is small -- to account for the existence of time zones and a 
> system-specific relation between the time recoreded by the system and one 
> handled by the RTC.  Also the feature is broken by design -- ntpd 
> shouldn't do that at all in principle and in practice it leads to the 
> system time being corrupted on some machines using an RTC interrupt for 
> the system timer tick.

Aren't we expected to keep UTC time inside the HW clock? So there's no
problem with timezones.  Also, if your timer interrupt source it that
broken that ntpd cannot track it, then you're having more servere
problems...

> > distributions seem to also update the HW clock at system shutdown time.
> 
>  Which is where it should really happen.

I disagree. IFF there's a known good time, it's acceptable to write it
into a backing HW clock. In case there isn't (any longer), it's probably
better to not write to the HW clock at all. Probably it's contents is
better than a wrongly manually adjusted local date setting...

I do trust ntpd, but do I trust someone who looks at it's watch?

> > So the correct solution to your problem is to either shutdown once
> > (workaround) or keep ntpd running (the solution[tm]).
> 
>  I think you've got the figures reversed (well, it's useful to have ntpd 
> running, but it should not fiddle with the RTC).

Well, I stated my oppinion. Maybe ntpd shouldn't set the clock (or make
the kernel set it internally), but for sure I don't want the HW clock
being set by hand (except very first power-up of the system) and by no
means if local time came up from a manual process.

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
fuer einen Freien Staat voll Freier Buerger" | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

Attachment: signature.asc
Description: Digital signature

<Prev in Thread] Current Thread [Next in Thread>