1

Does NTP daemon(ntpd) provide some sort of virtual clock that it disciplines and serves, but not touch the system clock?

Goal:

On a realtime Linux OS, have a NTP synchronized clock alongside of the system clock, so that ntp time changes won't cause issues on the system, but I can use NTP time for debuging purposes, say for sysloging.

Problem:

We are adding NTP to an already existing system, previously no worries about the system time, but now we are adding NTP to enable better debugging

Setup:

  • Some of the applications on the system rely on REALTIME instead of MONOTONIC time
  • I have local clock as one of the NTP servers
  • By default no external NTP server set
  • On boot, ntpd is set to instant sync the system clock to first available non local clock and exit, then start another instance of ntpd normally
  • When no external NTP server set, system would just run with ntpd with local clock

Scenario:

  • Lets say on boot time no NTP server set, and one decides to not set any NTP server
  • Applications are starts running against REALTIME, no problem
  • Someone decides to set an NTP server, but not to reboot the system
  • Assume the newly added NTP server is good time source better than local clock, but there is an offset(could be a minute, day or even a month)
  • If ntpd on the boot is set to allow huge offset stepping, it would do so without problem, but applications on the system could panic(timeout, etc)
  • If ntpd on the boot is set to allow only slew, but no stepping, because of the huge offset the system could take forever to sync to the actual NTP server time
  • 3
    "... so that NTP time changes won't cause issues on the system": what issues are they causing you now? ntpd is pretty careful not to do things that would upset the system, so you may be solving a non-problem. – MadHatter Mar 28 '16 at 21:38
  • I'm with MadHatter, but assuming you really need this...If you don't need to query the time very often, you could just do an ntpdate to a remote host to get the "real" time when you need to write logs. If your realtime system has a precise clock, but you don't want to sync it to the real time, you could compare the local time to the realtime at boot time, and store the offset. Then use that stored offset when writing the log messages. – Dan Pritts Mar 28 '16 at 21:58
  • I'm curious what issues are expected when running with slew only, ntpd -x – John Mahowald Mar 29 '16 at 0:34
  • @MadHatter None noticed yet, but one I can think of is stepping. The environment the system will be in will allow people to change the NTP server and lets say if some one decides to change the NTP server of the system and if that causes a backwards stepping when say a command like sleep is running, it would be preety bad for the operations of the applications running on the system. I know it is a very rare situation when stepping happens, but I would like to make it fault taulerant as possible. Thanks. – Vikyboss Mar 29 '16 at 1:14
  • 1
    ntpd doesn't step the clock, unless you make it; it slews it (as John has noted). Changing the NTP server shouldn't be a problem, unless (a) the new server is wrong, and (b) someone manually steps the clock to it. So forgive me, but this is looking more and more like a non-problem. Or is this your way of telling us that your organisation uses NTP for something other than intended (specifically, synchronising a bunch of servers to a time which isn't the right time)? – MadHatter Mar 29 '16 at 4:40
2

It seems to me that you are asking how to have Linux have a split-brain clock: one that never step-changes but can be wrong, for the kernel, and one that is right but may step-change, for everything else. Sadly, Linux doesn't support this idea, and it would take a lot of work to make it do so.

In your situation, things I think you can do to improve matters include:

  1. Don't run ntpd with local clock configured as a source unless the local clock is highly-accurate (which in your case it is not, or the problem wouldn't have arisen).

  2. Don't let people reconfigure and/or start ntpd under a running system unless they know what they're doing.

  3. Ensure the system runs hwclock --systohc on shutdown so that the system time is written to the hardware clock. At some point, the system is likely to acquire a good time signal, and this will help preserve it. After that point, the system will have a pretty good clock from boot onwards, and post-boot acquisition of a decent ntp server will be within the corrective capacity of clock slew.

  • Thanks @MadHatter. As you said as of now Linux doesn't support my requirement. Thanks for your suggestions. – Vikyboss Apr 9 '16 at 18:32
  • @Vikyboss you might want to accept this answer, or delete the question; otherwise, it'll hang around for ages like a querulous albatross, and that's not the best outcome. – MadHatter Apr 10 '16 at 10:42

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.