1

If I start $ ntpq -p promptly, after a reboot, I can see that the system clock is off by up to 600ms.

It takes a while before it converges to the correct NTP time, therefor mildly irritating in our use-case. (Ceph monitors, which are time-sensitive). A following reboot would again show a skewed clock.

Is this to be expected after a reboot, i.e., is the RTC of a PC that inaccurate?

Things I've done to investigate:

  1. Have seen it on multiple, though very similar, servers (HP dl360 gen9). But also an old white label desktop from 2009.
  2. Saved a converged NTP time to the RTC, and then copied from the RTC to the system clock. I can only see in the order of 10ms of skew. Perhaps naive, but this basically mimics a reboot as far as the system-time is concerned.
  3. Explicitly saved to RTC before rebooting; it still occurs
  4. Used kexec-reboot; it still occurs.
  5. So far only tested with ubuntu 16.04.
2

It's quite possible the RTC only stores seconds, and thus (unless the kernel can tell when it switches from one second to the next) it inherently is off by up to ½ second, i.e, 500ms. The same applies when saving time to the RTC; unless the kernel can control when the 1s tick happens, the save is off by up to 500ms.

The obvious workaround is to make NTP fix it quicker: if you start ntpd with -g (or even more forcefully, -G), it'll be allowed (or forced) to step the clock on boot. Taken together with iburst on your server/pool lines, that should get you an accurate clock within ten seconds or so.

You can then use, e.g., ntp-wait to not start your time-sensitive workloads until NTP is ready.

  • I thought so as well, but that's why I tested saving to RTC, and then reading from RTC back to system-clock (See point 2. in the Question). If your (and also my) theory was correct, we could expect a clock skew with a value taken from a uniformly distributed variable between 0 and 1000ms, but that doesn't seem to be the case. – hbogert Jul 18 '17 at 17:57
  • Hmm, I need to do more testing before my "doesn't seem to be the case" can actually be claimed. I'll update here. – hbogert Jul 18 '17 at 18:10
  • @hbogert Well, if it's actually the clock being fast or slow (and not just an error introduced by the set or read of it), then if your 60-second reboot gains/loses a half a second, you'd expect if left it in grub for a few minutes, it'd gain/lose a few seconds. I doubt that's the case. Regardless of the cause though, the workaround applies. – derobert Jul 18 '17 at 18:14

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.