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
Vikyboss
  • 121
  • 3
  • 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 00: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 01:14
  • @DanPritts I need the NTP time pretty often, especially in sysloging. Say my syslogging needs to be precise and doing ntpdate everytime I need to syslog will mean loss of logging time accuracy. Good point, I could take the offset at the boot time, but issues are the NTP server can be changed later after boot and offset might change, even say I can recalulate the offset, it is not just the offset that is important, the frequency at which my system clock ticks vs the NTP server clock, etc are all calulated by ntpd, which is why I'm keen on using NTP. Thank you. – Vikyboss Mar 29 '16 at 01:22
  • @JohnMahowald Good point. But once I built the system, the system is available for people to change the NTP servers, which could mean in worst case an offset that a normal ntpd operation is to step, but if I go with slew only it would take really longer to synchronize(e.g, from man ntpd: ... 2,000 s for each second the clock is outside the acceptable range.). Yes, it is very rare, but just trying to make it as fault taulerant as possible. Since some applications rely on Realtime instead of Monotonic clock, slewing/stepping could upset the system. Hence I decided ntp for logging only. Thanks. – Vikyboss Mar 29 '16 at 01:42
  • 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 04:40
  • @MadHatter Thanks for taking time to help. I have edited my question with bit more details and explanations. As explained in *Scenario*, it could mean we have a local clock that is not correct in the beginning, but later we adding a a good/right NTP server. – Vikyboss Mar 29 '16 at 14:45

1 Answers1

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.

MadHatter
  • 78,442
  • 20
  • 178
  • 229
  • Thanks @MadHatter. As you said as of now Linux doesn't support my requirement. Thanks for your suggestions. – Vikyboss Apr 09 '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