[arch-general] OK so HARDWARECLOCK="localtime" is "strongly discouraged" BUT???

[Tom Gundersen]

On Sat, Jul 16, 2011 at 5:36 PM, Joe(theWordy)Philbrook <jtwdyp at ttlc.net> wrote:
> myhost login: jtwd
>        NTP: adjust RTC [0000012.0000001]yp
> Password:
>
> Or some such thing. So unless the ntpd called from rc.local is NOT supposed
> to leave a message on tty1, I don't think that's a bug.

Ah, I see. That's as expected then.

>> hwclock has two purposes: adjusting for timezone offset (this is unchanged)
>> and adjusting for drift (this is incompatible with ntpd/dualboot and is now in
>> a separate daemon).
>
> So then, If I understand you correctly, IF I'm going to use hwclock to fix
> RTC to localtime by including it in my daemons array, then I probably
> shouldn't put ntpd in the array as well or sooner or later the two daemons
> will be in conflict???

Hmm, no. What I meant is: The call to hwclock which adjusts for
localtime, is independent of anything you put in your daemons array.
It is only controlled by the HARDWARECLOCK variable in rc.conf.

By putting hwclock or ntpd in DAEMONS (and you should not put both)
you will adjust the time for drift, and this has nothing to do with
the UTC v. localtime.

> (and if so, is that "incompatibility" likely to manifest itself when
> hwclock is deamonized and ntpd is called once at startup {via rc.local}??)

The incompatibility is that hwclock will calculate (based on the
values you use when you set/adjust the clock manually) how much your
RTC drifts and will adjust for this. ntpd will update the RTC every 11
minutes to be in sync with the system time. If ntpd has already
corrected the RTC, then hwclocks calculations will be wrong and it
will overadjust.

Again, these things are just about the drift, so you will probably not
notice (it will only be a few seconds here and there).

Though, I don't want to think about what happens to hwclock's drift
calculations when you manually adjust for DST... Probably nothing
good.

> The way I see it, that if I'm going to keep my RTC set to local time, my choices are:
>
> 1) deamonize both
> (and let the daemons duke it out???)

No, never use both the ntpd and hwclock daemons.

> 2) deamonize hwclock and call ntpd in rc.local
> (may have similar if less persistent issue as above)

No. The hwclock daemon relies on being the only one adjusting the time
(if you have multiple OS'es, only one of them can touch the time or
you get in trouble), so don't call ntpd if you use the hwclock daemon.

> 3) deamonize ntpd and somehow call hwclock once at startup
> (would ensure that some attempt was made to adjust for "incorrect" startup
> system time due to local time being stored in the RTC, even if the internet
> isn't available, but may have the same risk of conflict as #2 AND may need
> to also somehow call hwclock at shut down to convert system time to
> localtime before the RTC is updated?)

The initscripts (have a look in /etc/rc.sysinit) already call hwclock
once on boot to set the timezone, so if you set
HARDWARECLOCK=localtime, and add ntpd to DAEMONS this is roughly what
you get.

> 4) deamonize only ntpd
> (But without hwclock how do I update the RTC with local time on shutdown?
> OR does the term "ntpd/dualboot" refer to some configuration of ntpd where
> it will somehow store localtime in the RTC on shutdown without having to
> use hwclock???)

ntpd will write the correct time to RTC every 11 minutes, so no need
to do anything with hwclock (except for the initial set that is done
for you).

> 5) deamonize only hwclock and depend on my am habit of glancing at the
> localtime value stored in the RTC via the bios setup screen, before the days
> 1st OS boot {and manually fixing if incorrect} to solve DST issues and any
> {power off} RTC drift,etc... (of course this way my system time will never be
> more accurate than the clock on my office wall..)

This will probably mean that hwclock's drift calculations will get
confused by your manual sets of DST.

My advice to you is:

Use ntpd and do not use the hwclock daemon. The only time using the
hwclock daemon makes sense is if you know that nothing else touches
the RTC (even other OS instances) and you are unable to use ntpd (and
you are using your RTC in UTC).

If you don't want/can't use ntpd, I suggest using nothing at all, and
just adjusting the time manually when you notice it being off
(basically treat your computer like an expensive wall clock).

-t

PS
Or better still: set your clock to UTC and use ntpd to keep things accurate.