Time is wrong

jiewmeng · 2012-03-12 13:49:05

I just installed Arch and I found the time to be wrong. Its OK on install when they ask to set the time etc and hardware clock is UTC, havent change that (perhaps I should change anyways sometime). Anyways, I can run ntpd -qg the time gets corrected but I believe after a restart, its wrong again.

nixpunk · 2012-03-12 14:05:52

https://wiki.archlinux.org/index.php/Time

karol · 2012-03-12 14:45:55

How much wrong is it.

Please post your rc.conf and the output of 'hwclock --debug'.

n1x4 · 2012-03-12 15:17:34

Set your HARDWARE='' to localtime in rc.conf.. You have it UTC.

karol · 2012-03-12 15:26:20

n1x4 wrote:

Set your HARDWARE='' to localtime in rc.conf.. You have it UTC.

Why should he do it?

HARDWARECLOCK="UTC"

is fine for most cases.

Mr. Alex · 2012-03-12 18:35:24

jiewmeng wrote:

Anyways, I can run ntpd -qg the time gets corrected but I believe after a restart, its wrong again.

You probably don't save time to BIOS. Arch loads time from BIOS on boot and your set may be incorrect.

# echo 'hwclock --utc -w' >> /etc/rc.local.shutdown

tomegun · 2012-03-12 22:46:52

Mr. Alex wrote:

jiewmeng wrote:
Anyways, I can run ntpd -qg the time gets corrected but I believe after a restart, its wrong again.
You probably don't save time to BIOS. Arch loads time from BIOS on boot and your set may be incorrect.
# echo 'hwclock --utc -w' >> /etc/rc.local.shutdown

This should not be needed, so if it is it is a bug somewhere. There are two cases:

* you use ntpd: if your time is VERY wrong, then you might want to manually set it correctly using hwclock, otherwise ntpd should tell the kernel to write to the RTC every 11 minutes.
* you don't use ntpd: then you should set the time manually (according to the most accurate timesource you have) once (if the time drifts, you can set it manually again when you have a noticeable difference, and hwcolck should be able to use these two measurements to calculate a drift rate). You should enable the hwclock daemon in rc.conf to adjust for the drift.

Using RTC in localtime is strongly discouraged, and will likely cause headaches (at least every time we change to and from DST). The only time this might be needed is if you dual-boot with a version of windows that can not be set to use UTC.

jiewmeng · 2012-03-13 00:42:50

@karol, heres my hwclock --debug:

hwclock from util-linux 2.20.1
Using /dev interface to clock.
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2012/03/13 08:37:51
Hw clock time : 2012/03/13 08:37:51 = 1331627871 seconds since 1969
Tue Mar 13 16:37:51 2012 -0.130070 seconds

It looks like my hwclock is in localtime indeed. Does hwclock refer to BIOS clock? So should BIOS time be in UTC or localtime? I believe it was UTC before, not sure why the change to localtime ...

aking9 · 2012-03-13 00:57:37

hwclock -s writes the system time to the hardware clock (BIOS)

hwclock -w writes the hardware clock to the system time

you should not run hwclock daemon and ntpd simultaneously, if you run ntpd disable hwclock in rc.conf by putting a ! before it.

ewaller · 2012-03-13 02:20:20

aking9 wrote:

you should not run hwclock daemon and ntpd simultaneously, if you run ntpd disable hwclock in rc.conf by putting a ! before it.

Works just fine here. What is your rational?

ewaller · 2012-03-13 02:26:39

jiewmeng wrote:

Does hwclock refer to BIOS clock?

Yes

So should BIOS time be in UTC or localtime?

Yes.

The clock in Linux is initialized from the hardware (BIOS) clock. After that initialization, the BIOS clock is irrelevant. If you run NTP, it continually adjusts the Linux clock.
the hwclock DAEMON writes the linux clock back to the BIOS clock at shutdown.

If you are also using an operating system from the USA's Pacific Northwest, and it is using "Internet time", it might be mucking with your BIOS clock, especially if that OS noticed that daylight savings occurred.

Mr. Alex · 2012-03-13 06:59:52

aking9 wrote:

hwclock -s writes the system time to the hardware clock (BIOS)
hwclock -w writes the hardware clock to the system time

You got it wrong. The "-w" option writes from system time to BIOS. Not the other way.

Mr. Alex · 2012-03-13 07:04:34

jiewmeng wrote:

So should BIOS time be in UTC or localtime?

You decide. If you only run GNU/Linux on your machine - UTC is the best choice. I also run Windows 7 and have BIOS in localtime so that Windows loads time as is. Windows may be able to work with UTC, I'm just not interested in tinkering with Win.

Mr. Alex · 2012-03-13 07:10:06

tomegun wrote:

otherwise ntpd should tell the kernel to write to the RTC every 11 minutes.

Just my 2 cents. I tried this out. Ntpd wrote time to BIOS ~every hour and those were only minutes. Hours were not synchronized.

tomegun · 2012-03-13 12:13:16

Mr. Alex wrote:

tomegun wrote:
otherwise ntpd should tell the kernel to write to the RTC every 11 minutes.
Just my 2 cents. I tried this out. Ntpd wrote time to BIOS ~every hour and those were only minutes. Hours were not synchronized.

Don't know why it would do it only every hour, but the fact that it ignores the hours is correct. This is to be compatible with the RTC being in localtime (there is no way for the kernel to know). Hence, to use this feature you first have to set the RTC "almost correctly" with hwclock, before letting ntpd take over.

-t

tomegun · 2012-03-13 12:14:37

aking9 wrote:

hwclock -s writes the system time to the hardware clock (BIOS)
hwclock -w writes the hardware clock to the system time

This is the other way around (check man hwclock), otherwise correct.

tomegun · 2012-03-13 12:20:04

ewaller wrote:

aking9 wrote:
you should not run hwclock daemon and ntpd simultaneously, if you run ntpd disable hwclock in rc.conf by putting a ! before it.
Works just fine here. What is your rational?

hwclock will try to calculate the "driftrate" based on the times you set the hwclock manually (if you never set it manually it will obviously not do anything). It will then correct for this driftrate at boot and adjust the RTC accordingly. To know how much the RTC needs to be adjusted hwclock relies on knowing when the RTC was last set.

However, if you run ntpd at the same time, ntpd will ask the kernel to adjust the RTC on its behalf, and there is no way for hwclock to know that this has happened. In other words the drift adjustments are completely bogus.

In most cases this does not matter as the drift is so small anyway, but then you might as well just disable hwclock altogether :-)

ewaller · 2012-03-13 13:20:47

tomegun wrote:

... if you run ntpd at the same time, ntpd will ask the kernel to adjust the RTC on its behalf, and there is no way for hwclock to know that this has happened. In other words the drift adjustments are completely bogus....In most cases this does not matter as the drift is so small anyway, but then you might as well just disable hwclock altogether :-)

Good argument. I have to think it through and, perhaps recalibrate my thinking. I thought drift rate related to how fast the kernel's clock drifted and NTP would "servo" the real time clock using the delta and rate information. I don't have NTP set up to write back to the BIOS clock. I am (was) unaware that hwclock had a drift mechanism built in as well.

I guess I'll spend some time today immersing myself in some man pages

tomegun · 2012-03-13 13:30:47

ewaller wrote:

I thought drift rate related to how fast the kernel's clock drifted and NTP would "servo" the real time clock using the delta and rate information. I don't have NTP set up to write back to the BIOS clock. I am (was) unaware that hwclock had a drift mechanism built in as well.

The system time (kernel/cpu) clock does not really drift, unlike the RTC clock which can drift quite a lot. Note that as far as I know ntpd does not support disabling "11-minute-mode" (see man hwclock), so as long as ntpd is running the kernel will write to the RTC.

ewaller · 2012-03-13 15:31:43

tomegun wrote:

The system time (kernel/cpu) clock does not really drift, unlike the RTC clock which can drift quite a lot.

I almost never do this with a developer (because I usually regret it), but I respectfully disagree Granted, the RTC BIOS clocks in consumer computers are terrible. The kernel clocks are much better, but are still subject to the the stability of the microprocessor crystal, generally on the order of 100 ppm. Combine that, with aging, and the variability of the load capacitance to "Pull" the frequency, and you may find that the system clock could drift a few minutes per year. It is my understanding that that is what which NTP was specifically designed to cope.

Note that as far as I know ntpd does not support disabling "11-minute-mode" (see man hwclock), so as long as ntpd is running the kernel will write to the RTC.

I've done my reading, and I now agree 100%. I had not ever heard of the 11 minute mode in the kernel. To other readers, the 11 minute mode is a kernel switch that is normally off, until something turns it on. When enabled, the kernel updates the really awful BIOS clock every 11 minutes with the more accurate system clock. NTP enables that 11 minute mode, and then tunes the system clock to keep it even more accurate. I also agree this would horribly confuse hwclock. (Pardon my anthropomorphism)

I love Linux, I learn something every day. Turning off the hwclock DAEMON immediately after I post this.

tomegun · 2012-03-13 15:59:52

ewaller wrote:

tomegun wrote:
The system time (kernel/cpu) clock does not really drift, unlike the RTC clock which can drift quite a lot.
I almost never do this with a developer (because I usually regret it), but I respectfully disagree Granted, the RTC BIOS clocks in consumer computers are terrible. The kernel clocks are much better, but are still subject to the the stability of the microprocessor crystal, generally on the order of 100 ppm. Combine that, with aging, and the variability of the load capacitance to "Pull" the frequency, and you may find that the system clock could drift a few minutes per year. It is my understanding that that is what which NTP was specifically designed to cope.

We agree, we just have different notions of "not really" ;-)

NTP's drift mechanism deals with drifting of the system time. hwclocks' drift mechanism deals with drift of the RTC. That said, the RTC is usually so bad that from its point of view, the system time is practically perfect.

I would wager that in most cases setting the time using NTP during boot (and wake-from-suspend), and ignoring drift of both systemtime and RTC is good enough for almost everyone.

On a related note, the chrony ntp implementation will deal with both system time and RTC and "do the right thing" whatever your setup (e.g. lack of network) and needs (e.g. a gps basestation) are (if I understood correctly), so that is something I have been meaning to look into.

aking9 · 2012-03-13 18:43:13

ewaller wrote:

aking9 wrote:
you should not run hwclock daemon and ntpd simultaneously, if you run ntpd disable hwclock in rc.conf by putting a ! before it.
Works just fine here. What is your rational?

Running the hwclock daemon is not recommended if running the NTP daemon as the NTP daemon also adjusts the hardware clock

https://wiki.archlinux.org/index.php/Hwclock

Arch Linux

#1 2012-03-12 13:49:05

Time is wrong

#2 2012-03-12 14:05:52

Re: Time is wrong

#3 2012-03-12 14:45:55

Re: Time is wrong

#4 2012-03-12 15:17:34

Re: Time is wrong

#5 2012-03-12 15:26:20

Re: Time is wrong

#6 2012-03-12 18:35:24

Re: Time is wrong

#7 2012-03-12 22:46:52

Re: Time is wrong

#8 2012-03-13 00:42:50

Re: Time is wrong

#9 2012-03-13 00:57:37

Re: Time is wrong

#10 2012-03-13 02:20:20

Re: Time is wrong

#11 2012-03-13 02:26:39

Re: Time is wrong

#12 2012-03-13 06:59:52

Re: Time is wrong

#13 2012-03-13 07:04:34

Re: Time is wrong

#14 2012-03-13 07:10:06

Re: Time is wrong

#15 2012-03-13 12:13:16

Re: Time is wrong

#16 2012-03-13 12:14:37

Re: Time is wrong

#17 2012-03-13 12:20:04

Re: Time is wrong

#18 2012-03-13 13:20:47

Re: Time is wrong

#19 2012-03-13 13:30:47

Re: Time is wrong

#20 2012-03-13 15:31:43

Re: Time is wrong

#21 2012-03-13 15:59:52

Re: Time is wrong

#22 2012-03-13 18:43:13

Re: Time is wrong

Board footer