# You normally don't need to do this if you run a ntp daemon.

## dogshu

/etc/conf.d/hwclock says that you don't need to set clock_systohc="YES" if you are running an ntp daemon.  I'm not sure that this comment is accurate.  All of my systems run ntp daemons.  When I set clock_systohc="no" my systems say that filesystems were mounted in the future on boot because the hardware clock is wrong.  When my systems are unable to contact an ntp server at boot time, their clocks are off.

Perhaps ntpd used to set the hardware clock, but no longer does?  This comment in /etc/conf.d/hwclock does not seem to be accurate.

----------

## AngelKnight

Yeah I think "badly drifting clocks" wasn't considered as "normal" by whomever wrote the comment  :Smile: 

----------

## dogshu

Is the hardware clock ever going to be set if clock_systohc="NO"?  It doesn't matter if the drift is significant or not.  If there is any drift at all the hardware clock will become wrong given enough time.  It seems to me that running ntpd is completely unrelated to syncing the hardware clock.

----------

## nlsa8z6zoz7lyih3ap

 *Quote:*   

> Is the hardware clock ever going to be set if clock_systohc="NO"?

 

My experience is that the hardware clock is not set under those circumstances. Also logic tells me the same thing.

 *Quote:*   

> It seems to me that running ntpd is completely unrelated to syncing the hardware clock

 

This is my experience too, although with the caveat that I use netdate rather than ntpd.

To keep things in sync I do one of the following

(1) Set clock_systohc="YES"  in /etc/conf.d/hwclock

or

(2) run netdate in my own local script which is

```
netdate utcnist.colorado.edu  ;hwclock --systohc
```

You are right; something has to set the hardware clock

I think that the coments in /etc/conf.d/hwclock are misleading, but if you ignore them everything does work as one would expect from the defns of

clock_systohc and clock_hctosys.

----------

## Ant P.

I think the default is "don't touch the hardware" due to historically buggy RTC chips and not wanting to break those computers. I agree though, it's not a very useful default.

----------

## cwr

Generally I don't want errors in the software (system) clock to be automatically passed

to the hardware clock at shutdown, since I don't run an NTP daemon.  If it's left alone

a hardware clock has predictable drift, which can be allowed for in setting the system

clock on startup.

(From time  to time I set the hardware clock by hand, immediately after setting the

system clock with ntpd -q).

Will

----------

