ntpd and HARDWARECLOCK setting in rc.conf

cappuccino_se · 2010-04-18 11:05:39

Hi guys!

Yesterday I installed the NTP daemon to keep my clock in sync. I followed the Arch wiki [wiki]http://wiki.archlinux.org/index.php/NTP[/wiki] and installed the ntp package. The ntp daemon is running fine but I have a question regarding the HARDWARECLOCK setting in rc.conf. According to the wiki the correct setting is something else than "UTC" or "localtime" so I set it to "ntp". Unfortunately this sets my clock 2 hours ahead (UTC + 4) of the real time every time I reboot or start my computer. The hardware clock shows the correct time though (my local time, UTC + 2). Of course the ntp daemon will adjust the time after a few minutes but it's a little annoying. I have tried deleting /var/lib/hwclock/adjtime with no difference. If I set HARDWARECLOCK to "localtime" everything is working fine and both clocks show the same time but I don't know which consequences that may have. Do you have any advice?

NME · 2010-04-18 12:26:37

i would also like to know this... i think it doesn't matter?

kfgz · 2010-04-18 14:02:55

If you set HARDWARECLOCK to UTC in rc.conf then you must set your hardware clock (BIOS) to UTC. Of course you also have to set correct TIMEZONE in rc.conf.
As for the localtime in rc.conf - consequences?... hmm... none?

cappuccino_se · 2010-04-19 14:22:49

kfgz wrote:

If you set HARDWARECLOCK to UTC in rc.conf then you must set your hardware clock (BIOS) to UTC. Of course you also have to set correct TIMEZONE in rc.conf.
As for the localtime in rc.conf - consequences?... hmm... none?

I'm sure this will work. But my question was why the Arch wiki says to set HARDWARECLOCK to something else than "UTC" or "localtime" if you want to use ntpd. In my case this caused my system time to be 2 hours ahead after every reboot before ntpd corrects it. My hardware clock is set to my local time (have Windows on another partition), maybe this has something to do with it? Can I set HARDWARECLOCK to "localtime" even with the ntp daemon running? This solves my problem but the wiki says not to (I have disabled the adjtime cron job).

berbae · 2010-04-19 15:52:12

I think the wiki part about ntpd is confusing.

The ntpd daemon operates on the system clock which is different from the hardware clock, also named RTC or BIOS clock.

At system startup, the system clock is set from the hardware clock once, and after that, the time is taken only from the system clock.
The ntpd daemon doesn't touch to the hardware clock, it adjusts only the system clock.

At shutdown the hardware clock is set from the system clock to keep the right time.

The cron.hourly job adjtime uses the command :
hwclock --adjust
which operates on the hardware clock, and so it doesn't interfere with the ntpd daemon actions.

So I think the wiki is not correct on this point, though the cron.hourly job seems indeed useless in this case, because when the machine is shut down, the hardware clock will be synchronized with the system clock with a correct time.

So I think that the HARDWARECLOCK variable in the /etc/rc.conf file should be set the the right value, either UTC or localtime, depending on the RTC clock setting at the system installation.

thestinger · 2010-04-19 20:35:49

I think HWCLOCK should be UTC but the cron job needs to be disabled/removed - afaik from reading the docs, ntpd takes note of both the software and hardware clocks and compensates for hardware drift - openntpd just does the software clock (ntp has a drift file in /var/lib/ntp/ntp.drift)

I don't know if adjtime will interfere with ntpd, but I have heard it suggested so I've left it in the article - it seems completely possible/logical that having two programs compensating for the same thing will result in problems (neither will know the real drift, and it will change based on the intervals at which the two modify it line up etc)

if this is wrong then feel free to edit the wiki page and fix it (it's a wiki for a reason)

Last edited by thestinger (2010-04-19 20:37:02)

thestinger · 2010-04-19 20:48:25

I've edited the wiki page for now and instead of the suggestion that the HARDWARE clock value be changed, it tells people to disable/remove the cronjob/script - even if ntpd DOES load the time from the hardware clock to software clock on boot, it can't be harmful for it to happen an extra time (and if ntpd is disabled or fails to load you still get your clock set)

berbae · 2010-04-19 22:19:13

The ntp.drift file is used to memorize how the system clock drifts from the right time, and is used to slow down or to accelerate it depending on the preceding measures kept in the drift file.
So it doesn't concern the hardware clock, and the ntpd daemon doesn't operate at all on the hardware clock :

The ntpd program is an operating system daemon that synchronizes the system clock with remote NTP time servers or local reference clocks.

It is not affected by the adjtime cron.hourly script which concerns the hardware clock.

This adjtime cron.hourly script may not be useful when using the ntpd daemon, as the hardware clock will be synchronized with the system clock by the 11 minutes kernel adjustment, which is enabled when using the ntpd daemon, or at a clean shutdown time.

But it seems to be useful, if the machine is not cleanly shut down and/or stays in a power off state for some time.

So is my understanding of the ntpd time synchronizing operations.

thestinger · 2010-04-19 23:41:04

I've re-read the docs on the ntp site and you seem to be 100% right. The first information I got was from the ntp article on the archwiki, and now that I think about it, I've seen/heard any kind of problems like this on any other sites. ntp should NOT break the hwclock utility - perhaps it was a bug at one point.

I've taken all the info about disabling the script/hardware clock setting out of the article and started running the cronjob again myself. If for some reason it does cause problems (which at this point I doubt), then I think it's a matter of filing a bug report upstream rather than telling people to use a workaround.

berbae · 2010-04-20 19:29:49

After looking a little closer to my system, I found that the adjtime cron.hourly script is definitely harmless to the ntpd operations,
because it does nothing when ntpd is running !
The reason is given in 'man hwclock' :

A small amount of error creeps in any time hwclock sets the clock, so it refrains from making an adjustment that would be less than 1 second.

As the hardware clock is synchronized with the system clock by the kernel every 11 minutes, when the adjtime cron.hourly script runs, there is always less than 1s to adjust, so nothing is done !
This is confirmed by looking in the /var/lib/hwclock/adjtime file used by hwclock ; on my machine it contains all the day long :

-0.015207 1271715855 0.000000
1271715855
UTC

It shows that the time of the more recent calibration is always the same as the time of the more recent adjustment.
On my machine it is the time of the last shutdown.
The -0.015207 value is the adjust value for one day and the correction for one hour would be -.0006336250 largely <1s.

So no adjustment is done during all the day by the adjtime script, because there is always less than 1s to adjust.

At shutdown the 'hwclock --systohc' is run and a very small adjust value is written in the /var/lib/hwclock/adjtime file with the new time of the more recent calibration. And the same goes the next day.

So definitely the adjtime cron.hourly script is really harmless to the ntpd daemon as it doesn't even touch to the hardware clock.

The only caveat is that the adjust value in /var/lib/hwclock/adjtime is not true, but it is unimportant if the ntpd daemon is always started at boot up and it is always running.

Last edited by berbae (2010-04-20 19:35:39)

Leonid.I · 2010-04-21 00:42:02

berbae wrote:

So definitely the adjtime cron.hourly script is really harmless to the ntpd daemon as it doesn't even touch to the hardware clock.

Well, it would be totally pointless, if it did. In fact, the hardware clock is only needed when you start the system, in order to synchronize the kernel clock. As long as the system is running, nothing should query the hardware clock.

Actually, I don't understand what do you guys mean by "hardware clock in UTC"? I thought hwclock has no format, it is how we understand it, what matters...

Also, what is the particular advantage of using NTPD over OpenNTPD? The latter is opensource and developed by OpenBSD project, and works out of the box -- I haven't even seen the wiki about it.

thestinger · 2010-04-21 01:14:29

Leonid.I wrote:

berbae wrote:
So definitely the adjtime cron.hourly script is really harmless to the ntpd daemon as it doesn't even touch to the hardware clock.
Well, it would be totally pointless, if it did. In fact, the hardware clock is only needed when you start the system, in order to synchronize the kernel clock. As long as the system is running, nothing should query the hardware clock.
Actually, I don't understand what do you guys mean by "hardware clock in UTC"? I thought hwclock has no format, it is how we understand it, what matters...
Also, what is the particular advantage of using NTPD over OpenNTPD? The latter is opensource and developed by OpenBSD project, and works out of the box -- I haven't even seen the wiki about it.

the hardware clock (BIOS clock) has time in UTC or localtime - a *nix OS will use UTC by default, windows uses localtime by default, hence the reason for the setting (people who dual boot); it's not a format difference, both UTC and localtime are the same format, but localtime is local time and UTC is universal coordinated time

OpenNTPD is called Open due to the roots in OpenBSD - ntpd is of course open source too and it's the standard linux ntp daemon

ntpd is the status quo ntp service (like bind is to DNS) - it has lots of features (therefore lots of code) so it's not as light on resources as it could be and it can be confusing for some users to configure

ntpd is designed for the super precise accuracy needed by some companies or projects (tiny fractions of a second) and OpenNTPD's goal is security and low resource use; less code == more security (the security aspect is the same thing the whole OpenBSD project focuses on)

I think the main feature difference is that ntp handles drift and OpenNTPD just ignores it

Last edited by thestinger (2010-04-21 01:18:03)

Leonid.I · 2010-04-21 01:42:34

OK, in my BIOS I set time as XX:XX:XX, and there is no reference to where it is local or not. When the linux kernel reads it it assumes that this is local/UTC, dependent on which setting is used in rc.conf. Win will always assume it's local. That's why I said that CMOS time is invariant in this sense -- the question is how your system understands it.

I'm sorry, I didn't want to imply that NTPD is proprietary...

I didn't know that OpenNTPD ignores drift -- nice to know

Arch Linux

#1 2010-04-18 11:05:39

ntpd and HARDWARECLOCK setting in rc.conf

#2 2010-04-18 12:26:37

Re: ntpd and HARDWARECLOCK setting in rc.conf

#3 2010-04-18 14:02:55

Re: ntpd and HARDWARECLOCK setting in rc.conf

#4 2010-04-19 14:22:49

Re: ntpd and HARDWARECLOCK setting in rc.conf

#5 2010-04-19 15:52:12

Re: ntpd and HARDWARECLOCK setting in rc.conf

#6 2010-04-19 20:35:49

Re: ntpd and HARDWARECLOCK setting in rc.conf

#7 2010-04-19 20:48:25

Re: ntpd and HARDWARECLOCK setting in rc.conf

#8 2010-04-19 22:19:13

Re: ntpd and HARDWARECLOCK setting in rc.conf

#9 2010-04-19 23:41:04

Re: ntpd and HARDWARECLOCK setting in rc.conf

#10 2010-04-20 19:29:49

Re: ntpd and HARDWARECLOCK setting in rc.conf

#11 2010-04-21 00:42:02

Re: ntpd and HARDWARECLOCK setting in rc.conf

#12 2010-04-21 01:14:29

Re: ntpd and HARDWARECLOCK setting in rc.conf

#13 2010-04-21 01:42:34

Re: ntpd and HARDWARECLOCK setting in rc.conf

Board footer