I have noticed in kernel 3.10, there is an option CONFIG_RTC_SYSTOHC

Device Drivers -> RTC -> Set the RTC time based on NTP synchronization

The help says:

If you say yes here, the system time (wall clock) will be stored
in the RTC specified by RTC_HCTOSYS_DEVICE approximately every 11
minutes if userspace reports synchronized NTP status.

I don't understand how I can make use of this function. Does it mean, I don't need any userspace tools anymore (ntpdate) to synchronize time ? How is this different from using ntpdate ? Where do I specify the ntp server to be used?

Could somebody please clarify ?

  • 2
    You still need a ntp client. See patchwork.kernel.org/patch/1864641 for more details – Ulrich Dangel Aug 21 '13 at 8:19
  • 1
    ntpdate is discouraged in favor of ntpd: "However, it is important to note that ntpdate with contrived cron scripts is no substitute for the NTP daemon, which uses sophisticated algorithms to maximize accuracy and reliability while minimizing resource use. Finally, since ntpdate does not discipline the host clock frequency as does ntpd, the accuracy using ntpdate is limited." says the ntpdate man page. – msw Aug 21 '13 at 10:00
  • ntpd is a daemon, which offers both ntp client, and ntp server. Why on earth should I run a sophisticated ntp daemon on my laptop, when all I want is to sync time once or twice a day? Besides, ntpd vs. ntpdate was not the point of my question. – Martin Vegter Aug 21 '13 at 11:02
  • 2
    @MartinVegter because ntpd will adjust time slowly while ntpdate makes jumps in time which can cause problems under specific circumstances. – Ulrich Dangel Aug 21 '13 at 16:37
  • what if I run ntpdate every 6 hours, or so, so that the jumps are few miliseconds. Can it still potentially cause problems? – Martin Vegter Aug 21 '13 at 18:25

Linux stores time internally, regardless of your hardware clock (a.k.a. RTC). That means your system can show one time when you run date (Linux clock), and a different time when you run hwclock (hardware clock).

Usually, you would want to load the time from the hardware to Linux when the machine boots (with hwclock -hctosys), and when the machine goes down, you want to store your pretty accurate time (you do use ntpd, don't you? ;)) - back to the hardware clock, with hwclock -systohc.

Now, what happens if your system dies, reboots abnormally, etc? The clock doesn't get synchronized to hardware. On next boot, you might have a large clock skew, because the hardware clock is not that accurate... next time you'll say "I need my system to start with ntpdate before ntpd, because otherwise, ntpd might not sync the time at all, because the delta on the current clock and the real time is too big". The problem with that approach is... what happens if you happen to sync to a machine which by itself is not in sync, and then your ntp will never have the right time?

So in order to avoid all that, it's good to keep the right time synchronized to the hardware at all times. What the kernel option you're asking about seems to do, is to note if your time is actually synchronized with NTP (there is a way to know that...) - and if it is - sync that time regularly from Linux time (a.k.a. System Time), to the hardware clock, so it will be very accurate at all times, including sudden system crashes.

  • OK, I have compiled the option in my kernel. What else do I need to do to make it work. How can I test that it realy works? – Martin Vegter Aug 22 '13 at 9:09
  • 1
    @MartinVegter Well, if your ntpd is running and synchronized successfully (e.g. you don't get a stratum 16 in ntpq -p), you can simply wait some amount of time where a drift would normally happen, and just verify if the output of date and hwclock is identical. If they're identical, that means that your hardware clock gets synchronized all the time, otherwise you would see a skew between the two accumulating over time... P.S. Remember you should make sure that RTC_HCTOSYS_DEVICE is set to the actual rtc device existing in your system, so the kernel will know to which RTC it should sync. – Shimi Aug 22 '13 at 16:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.