0

I'm running a couple of servers which need a pretty tight time sync (<50ms) as they are running a Paxos algorithm. The servers are running NTP and are successfully sync at one point. According to hwclock the 11-minute mechanism is enabled, so the system time should be copied to hardware clock.

However, I see that after a reboot the system time can be off by as much as 300ms compared to the time just before a reboot. Is it unreasonable to think that after a reboot the time should be within 50ms of the time just before reboot?

5
  • Have you considered replacing the Paxos algorithm with an asynchronous algorithm?
    – kasperd
    Feb 12, 2018 at 0:29
  • Outdated. In 2018 keeping servers in sync within 1ms is trivial, standard and in some industries legally mandated (banking, trading) for auditing purposes. Being hundreds of MS off means either really crappy hardware (by todays standards) or - all answers are wrong and there is aserious issue in configuration.
    – TomTom
    Jun 17, 2018 at 17:55
  • @TomTom Or there is a third option, that is you are wrong, and it is not trivial after a reboot to have ms accurate time.
    – hbogert
    Jun 18, 2018 at 10:17
  • @hbogert Ah, let's see. WIndows does it out of the box. You may want to check docs.microsoft.com/en-us/windows-server/networking/… for a decent explanation - not only on situation there ,but they go into some details naming the legal requirements. You can easily solve that by virtualizing your Linux into Hyper-V - problem solved, time stable to less than 1ms. Now, for a reboot jsut wait a minute before starting processing after a reboot. Done.
    – TomTom
    Jun 18, 2018 at 10:25
  • @TomTom You realize you just gave the exact solution of answers below; waiting on NTP sync before starting other processes. The original question was clearly about how it's possible that after a reboot, time can be off by multiple hundreds of milliseconds. I'm not sure what the addition of Microsoft Windows solves of the fundamental problem given in the question.
    – hbogert
    Jun 19, 2018 at 10:53

2 Answers 2

3

My initial reaction was that 300ms seems like an awful lot, but I do have numbers to produce, and they show that @Law29 is right:

  1. One of my machines over a normal week:
    • Frequency: frequency
    • System peer offset: sysoffset
  2. Same system, shorter period with a reboot involved:
    • Frequency: frequency-reboot
    • System peer offset: sysoffset-reboot
    • Scatter plot of the peers peerstatsplot-reboot

(Hope you can read all the numbers on the graphs OK - drop me a comment if not.)

As you can see, there's a rather large discrepancy. It surprised me how much it was, and also how long it took to get back on track with the frequency correction, considering that there's a stratum 1 GPS source on my local network. And given that the peer samples are fairly tightly clustered on the plot, it's clearly a problem with the local clock, not inconsistent network delay during startup. (For the record, the hardware is a Shuttle DS437 fanless mini-PC with a dual-core Celeron 1037U @ 1.8 GHz.)

So the takeaways are probably:

  1. make sure ntpd is successfully writing the NTP drift file,
  2. make sure the kernel's 11-minute timer to update the hardware clock is on (See "Automatic Hardware Clock Synchronization by the Kernel" in man hwclock for details), or your shutdown process is updating the hardware clock,
  3. make sure ntpd has 4-10 reachable sources (in iburst mode), and
  4. configure your startup dependencies so that ntpd has a chance to fix the clock before Paxos starts.
7
  • Not sure how I should interpret your second graph. Further, the drift file of NTPd is not for correcting the hardware clock right? The takeaway of saving to hwclock on shutdown seems to be outdated as well, since a lot of distro's nowadays use Systemd whose services rely on the 11-minute kernel mechanism. I am going to monitor it just like you I guess.
    – hbogert
    Feb 12, 2018 at 10:14
  • The second graph is just the usual system offset over a week, the point of which is merely to show that it can keep reasonably close time (+/- 5ms max/min, average around 1ms) normally, whereas I got large positive & negative offsets after the reboot.
    – Paul Gear
    Feb 12, 2018 at 11:26
  • The drift file is where ntpd saves the local clock frequency error on an hourly basis. It uses it on startup as a seed to reduce amount of work it has to do to calculate it. But if it's not writing it (it's surprising how many times simple permissions problems break things), then it will necessarily be less accurate after reboot.
    – Paul Gear
    Feb 12, 2018 at 11:28
  • The 11-minute timer was a new one on me. Looks like ntpd will turn it on normally as well. So the main thing is to confirm that it's actually on and working.
    – Paul Gear
    Feb 12, 2018 at 11:33
  • And have you checked that your ntpd is actually stepping not slewing at boot? Are you using -g only or -gx? I know -x shouldn't change anything and that -g should step if offset is over 128ms, but can't hurt to be sure. Maybe the initial ntpd estimate is off and the initial stepping actually hurts! Chrony might handle things better.
    – Law29
    Feb 12, 2018 at 11:45
5

I do not have numbers to produce, but it seems probable that the interface used to set the clock at boot only has precision down to the second.

You do not state your OS, but on all Unix-like systems it is possible to insert a dependency on NTP time in the boot process.

The NTP daemon is started at boot, but often it immediately backgrounds itself and boot continues while the NTP daemon looks for servers to sync to -- this is so that boot is not delayed in case the machine is not connected to the network.

In this case, you will want to make sure that the ntp daemon is started in a way that will correct an offset by stepping at boot. This can be, for example, ntpd -gx or chronyc -q. You may also wish to insert a check that the offset is acceptable before starting your workload.

9
  • can you name a technical cause for the hundreds of milliseconds drift during a reboot?
    – hbogert
    Feb 11, 2018 at 22:04
  • 2
    Not really. Even the pre-HPET clocks have a precision of some 0.03 ms (2^15 Hz). Maybe the time is not actually written to the hardware clock (you can check that by reading it and comparing to the system clock), or maybe there is some problem when reading it during the boot process.
    – Law29
    Feb 11, 2018 at 22:22
  • 2
    Just to clarify, I think that sub-50ms is a bit too too demanding, but 300ms is quite a lot. It could actually be that the time is being set with a one-second resolution somewhere.
    – Law29
    Feb 12, 2018 at 8:02
  • 1
    There should be no need to do the equivalent of ntpdate -b before starting ntpd on most distros; -g is included by default, which allows the first step to be large.
    – Paul Gear
    Feb 12, 2018 at 8:58
  • @PaulGear yes, added (I'd call it kind of an equivalent of ntpdate -b, but ntpd -g is the preferred way to do it)
    – Law29
    Feb 12, 2018 at 10:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .