You are not logged in.
Pages: 1
Hello. I just read the wiki guide about NTP, but it seems there's a contradiction when it tells about hwclock.
You should also ensure that the hwclock daemon is added to the DAEMONS array, unless something other already takes care of updating the hardware clock, for example another operating system in dual boot.
Add ntpd to your DAEMONS array so it starts automatically on boot and make sure hwclock is disabled:
At the moment I have ntpd in /etc/rc.conf but no hwclock, but I'm not sure if it is the correct way to go.
Does anyone know more?
Thank you.
Last edited by fturco (2012-08-13 09:01:00)
Offline
I followed the instruction that says not to run hwclock with ntpd. I don't know which instruction is correct, but things seem to be working perfectly.
Tim
Offline
At the moment I have ntpd in /etc/rc.conf but no hwclock, but I'm not sure if it is the correct way to go.
It is. If you have htpd in /etc/rc.conf, you don't need hwclock.
Offline
More info in thread.
Offline
You *do not* need hwclock if you are using the ntp daemon.
Offline
If you read the wiki regarding what each actually does, you will see why both are not needed. I think it tells you to add hwclock initially because it is recommended that you have *something* to take care of drift, so it is there to ensure that you don't go with nothing. Otherwise, you may run into a situation where the clock is forced to change significantly when you fix it, which has bad implications for some programs.
Offline
Never use hwclock if you either use ntpd or dual-boot. Always use ntpd if you can.
Offline
hwclock is good to write time to BIOS on shutting down or rebooting.
Offline
@Mr. Alex: ntpd will do this for you. if you run both ntpd and hwclock they'll get confused and interfere with eachother.
Offline
1. Ntpd will not sync hours, only minutes.
2. I was talking about adding "hwclock --utc -w" to "/etc/rc.local.shutdown" only.
Offline
@Mr. Alex
1) ntpd syncs over a fairly large minute range. See "man ntpd":
-x, --slew
Slew up to 600 seconds.
Normally, the time is slewed if the offset is less than the step thresh‐
old, which is 128 ms by default, and stepped if above the threshold.
This option sets the threshold to 600 s, which is well within the accu‐
racy window to set the clock manually. Note: Since the slew rate of
typical Unix kernels is limited to 0.5 ms/s, each second of adjustment
requires an amortization interval of 2000 s. Thus, an adjustment as
much as 600 s will take almost 14 days to complete. This option can be
used with the -g and -q options. See the tinker configuration file
directive for other options. Note: The kernel time discipline is dis‐
abled with this option.
2) Not sure if this would work at all. But even if so, to write the current clock to the system clock the "-s" (or --hctosys) parameter must be used.
To know or not to know ...
... the questions remain forever.
Offline
2. No.
-w, --systohc
Set the Hardware Clock to the current System Time.
Offline
1. Ntpd will not sync hours, only minutes.
Wrong...
-g, --panicgate
Allow the first adjustment to be Big. This option may appear an
unlimited number of times.Normally, ntpd exits with a message to the system log if the
offset exceeds the panic threshold, which is 1000 s by default.
This option allows the time to be set to any value without
restriction; however, this can happen only once. If the thresh‐
old is exceeded after that, ntpd will exit with a message to the
system log. This option can be used with the -q and -x options.
See the tinker configuration file directive for other options.
2. I was talking about adding "hwclock --utc -w" to "/etc/rc.local.shutdown" only.
I think it's a bad idea to touch hwclock, without a decent understanding of what the kernel, ntp, and hwclock does (which I'm a bit too lazy to do).
As another example of the complexity:
8.3.1.1.2. How can I set the CMOS clock?
Basically ntpd only sets the system time of the operating system. Therefore setting the CMOS clock is the responsibility of the operating system and its associated tools. To make things worse, typical PC operating systems and the BIOS set the RTC to local time, while UNIX-like operating systems set the RTC to UTC.
Example 11. Linux
In Linux the RTC is either not updated at all, or just the minutes and seconds. The related kernel code has been revised several times, with different behaviour. Setting the system time manually does not update the RTC. Only if the STA_UNSYNC bit is cleared, the kernel will periodically update the RTC from the system time. Typically this happens every 11 minutes.
With the optional PPSkit-0.9.0 kernel patch the RTC is updated just like in other PC operating systems. In addition the automatic periodic update can be disabled completely (see the documentation that comes with the product).
There is also a user-space program to set the RTC, but it requires special privileges. Typically the utility is named hwclock.
Offline
brebs, so what's the problem in using hwclock to save system time to hw? I know that ntp gets complicated sometimes and I use it to only adjust system time while my PC is on. Then when it's going to halt/reboot, "hwclock --utc -w" is executed. I don't see any problem here.
Offline
what's the problem
There's a lot of uncertainty about whether using hwclock is beneficial, or even harmful, especially with the additional subtlety of /etc/adjtime
So any recommendatation for its usage should come with a decent explanation.
It would be interesting to see whether other major distros run hwclock when ntp is installed.
Offline
Mr. Alex wrote:what's the problem
There's a lot of uncertainty about whether using hwclock is beneficial, or even harmful, especially with the additional subtlety of /etc/adjtime
So any recommendatation for its usage should come with a decent explanation.
It would be interesting to see whether other major distros run hwclock when ntp is installed.
afiak fedora 17 only uses chrony and doesn't issue hwclock (past versions issued hwclock command on shutdown, but this was changed in fedora 17 I believe). No idea what ubuntu does.
Offline
Very interesting. Looks like a switch to chrony might be my future recommendation - I will check it out.
The FAQ says:
9.2. I want to use chronyd's real-time clock support. Must I disable hwclock?
The hwclock program is often set-up by default in the boot and shutdown scripts with many Linux installations. If you want to use chronyd's real-time clock support, the important thing is to disable hwclock in the shutdown procedure. If you don't, it will over-write the RTC with a new value, unknown to chronyd. At the next reboot, chronyd will compensate this (wrong) time with its estimate of how far the RTC has drifted whilst the power was off, giving a meaningless initial system time.
Offline
Very interesting. Looks like a switch to chrony might be my future recommendation - I will check it out.
The FAQ says:
9.2. I want to use chronyd's real-time clock support. Must I disable hwclock?
The hwclock program is often set-up by default in the boot and shutdown scripts with many Linux installations. If you want to use chronyd's real-time clock support, the important thing is to disable hwclock in the shutdown procedure. If you don't, it will over-write the RTC with a new value, unknown to chronyd. At the next reboot, chronyd will compensate this (wrong) time with its estimate of how far the RTC has drifted whilst the power was off, giving a meaningless initial system time.
I'm using it right now, along with the chrony networkmanager dispatcher, works perfectly
Offline
brebs, so what's the problem in using hwclock to save system time to hw? I know that ntp gets complicated sometimes and I use it to only adjust system time while my PC is on. Then when it's going to halt/reboot, "hwclock --utc -w" is executed. I don't see any problem here.
The problem is that hwclock uses /etc/adjtime to track the "drift" of the RTC. For the calculation to work it is important that nothing else adjusts the RTC without hwclock knowing it (as that would look like the RTC is drifting A LOT).
Therefore, if you use ntpd (which will adjust the RTC by default), or if you use a second OS (which might be adjusting the RTC on its own), then hwclock will get completely confused as to what the real driftrate is, and might end up trying to "adjust" for an imaginary drift rate and your clock will be very wrong (much worse than just leaving it alone).
Someone mentioned chrony: this is my personal favorite as it deal with both RTC and NTP.
Offline
As an aside, no .service file currently exists for ntpd (unless I'm looking in the wrong spot); one must either write one or use hwclock if using systemd.
Personally, the couple times my clock has gotten screwed up, I've used ntpd to update the correct time, then run "hwclock -w" to write it to the system clock. It's never caused any problems for me.
Offline
As an aside, no .service file currently exists for ntpd (unless I'm looking in the wrong spot); one must either write one or use hwclock if using systemd.
Personally, the couple times my clock has gotten screwed up, I've used ntpd to update the correct time, then run "hwclock -w" to write it to the system clock. It's never caused any problems for me.
its just ntp.service
Offline
I read better the wiki article about NTP, and now I think I understood.
The article is correct, because it says to use hwclock only if you don't run ntpd daemon continuously, but you just run ntpd -qr at boot time. The latter command fix the system time only, and hwclock fixes the hardward time according to the system time.
When using ntpd daemon continuously, it takes care of updating both the system time and the hardware time, so hwclock becomes unnecessary.
Offline
So please mark the thread [SOLVED] then, fturco.
To know or not to know ...
... the questions remain forever.
Offline
ANOKNUSA wrote:As an aside, no .service file currently exists for ntpd (unless I'm looking in the wrong spot); one must either write one or use hwclock if using systemd.
Personally, the couple times my clock has gotten screwed up, I've used ntpd to update the correct time, then run "hwclock -w" to write it to the system clock. It's never caused any problems for me.
its just ntp.service
Well, of course it is. Didn't think about that; it's another case of the systemd unit name not matching the daemon name.
Offline
Are you sure? This is used in my system:
bp:~$ locate ntpd.service
/etc/systemd/system/multi-user.target.wants/ntpd.service
/usr/lib/systemd/system/ntpd.service
bp:~$ pacman -Qo /usr/lib/systemd/system/ntpd.service
/usr/lib/systemd/system/ntpd.service is owned by ntp 4.2.6.p5-7
To know or not to know ...
... the questions remain forever.
Offline
Pages: 1