7

My OpenBSD host is running NTPD but is 26 seconds slow, despite it saying "clock synced":

user@host:~# ntpctl -sa
4/4 peers valid, clock synced, stratum 3

peer
   wt tl st  next  poll          offset       delay      jitter
216.239.35.0 time1.google.com
    1 10  2 1063s 1078s        -1.951ms   101.103ms     0.594ms
216.239.35.4 time2.google.com
 *  1 10  2  481s 1067s        -1.742ms   112.251ms     0.447ms
216.239.35.8 time3.google.com
    1 10  2  729s  991s        -1.472ms    11.454ms     0.169ms
216.239.35.12 time4.google.com
    1 10  2  830s 1051s        -2.203ms   268.285ms     8.564ms

/etc/ntpd.conf contents:

server time1.google.com
server time2.google.com
server time3.google.com
server time4.google.com

/etc/rc.conf.local contents:

nsd_flags=
ntpd_flags=-s
unbound_flags=
dhcpd_flags=vmx0

uname -a output:

OpenBSD host.domain.xxx 6.0 GENERIC.MP#2319 amd64

I'm using Google's recently introduced time servers. I have several Debian machines (Linux hostname 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux) that are correctly synced.

After changing /etc/ntpd.conf and /etc/rc.conf.local I restarted NTPD and even rebooted. It is still behind.

I tried ntpd -s -d which gives:

user@host:~# ntpd -s -d
ntp engine ready
reply from 216.239.35.8: offset -0.002133 delay 0.011241, next query 9s
set local clock to Thu Dec  1 16:50:01 CET 2016 (offset -0.002133s)
reply from 216.239.35.0: offset -0.001434 delay 0.099329, next query 8s
reply from 216.239.35.4: offset -0.001749 delay 0.109564, next query 8s
reply from 216.239.35.12: offset -0.001908 delay 0.263908, next query 9s
reply from 216.239.35.0: offset -0.000319 delay 0.101452, next query 7s
reply from 216.239.35.4: offset -0.000641 delay 0.111670, next query 9s
reply from 216.239.35.8: offset 0.000052 delay 0.011303, next query 8s
reply from 216.239.35.12: offset -0.000872 delay 0.266129, next query 8s
reply from 216.239.35.0: offset -0.000597 delay 0.101577, next query 5s
reply from 216.239.35.8: offset -0.000018 delay 0.011269, next query 6s
reply from 216.239.35.4: offset -0.000755 delay 0.111866, next query 5s
reply from 216.239.35.12: offset -0.000842 delay 0.265926, next query 6s
peer 216.239.35.0 now valid
reply from 216.239.35.0: offset -0.000587 delay 0.101456, next query 5s
peer 216.239.35.4 now valid
reply from 216.239.35.4: offset -0.005059 delay 0.120511, next query 6s
peer 216.239.35.8 now valid
reply from 216.239.35.8: offset 0.000012 delay 0.011377, next query 9s
peer 216.239.35.12 now valid
reply from 216.239.35.12: offset -0.000859 delay 0.266074, next query 8s
reply from 216.239.35.0: offset -0.000591 delay 0.101480, next query 5s
reply from 216.239.35.4: offset -0.000681 delay 0.111761, next query 8s
reply from 216.239.35.0: offset -0.000675 delay 0.101565, next query 6s
reply from 216.239.35.12: offset -0.000896 delay 0.266249, next query 9s
reply from 216.239.35.8: offset -0.000090 delay 0.011496, next query 6s
reply from 216.239.35.0: offset -0.000676 delay 0.101632, next query 33s
reply from 216.239.35.4: offset -0.000636 delay 0.111738, next query 7s
reply from 216.239.35.8: offset 0.000037 delay 0.011290, next query 9s
reply from 216.239.35.12: offset -0.000871 delay 0.266122, next query 8s
reply from 216.239.35.4: offset -0.000649 delay 0.111825, next query 31s
reply from 216.239.35.8: offset 0.000018 delay 0.011296, next query 32s
reply from 216.239.35.12: offset -0.000922 delay 0.266301, next query 30s
reply from 216.239.35.0: offset -0.000634 delay 0.101520, next query 32s
reply from 216.239.35.4: offset -0.000732 delay 0.111862, next query 30s
reply from 216.239.35.8: offset 0.000041 delay 0.011358, next query 32s
reply from 216.239.35.12: offset -0.000903 delay 0.266024, next query 31s
reply from 216.239.35.0: offset 0.001242 delay 0.101406, next query 34s
reply from 216.239.35.4: offset -0.000638 delay 0.115180, next query 33s
reply from 216.239.35.12: offset 0.000838 delay 0.266193, next query 34s
reply from 216.239.35.8: offset 0.001788 delay 0.011284, next query 34s
clock is now synced
reply from 216.239.35.0: offset -0.000130 delay 0.101597, next query 33s
reply from 216.239.35.4: offset -0.000103 delay 0.111680, next query 34s
reply from 216.239.35.8: offset 0.000554 delay 0.011275, next query 30s
reply from 216.239.35.12: offset -0.000391 delay 0.266116, next query 33s
reply from 216.239.35.0: offset -0.000070 delay 0.101481, next query 32s
reply from 216.239.35.4: offset -0.000163 delay 0.111739, next query 33s
reply from 216.239.35.8: offset 0.000451 delay 0.011480, next query 31s
reply from 216.239.35.12: offset -0.000396 delay 0.266210, next query 30s
^Cntp engine exiting
Terminating

Same here, a few lines up from the bottom it says "clock is now synced", but still it's behind ~26 seconds. It's been over a day and it's just as much off as yesterday so it doesn't seem to be correcting slowly (or it's correcting very slowly).

edit: as pointed out by Rui F Ribeiro; I forgot to mention the machine is a VM (guest) running on a ESXi 6 host. The aforementioned Debian machines/guests are, however, on the same host. My logic was that, since they seem to work OK, OpenBSD shouldn't be any different?

What can I do/try to get my OpenBSD to sync correctly?

edit: as requested by Bink the (ntpd events from) /var/log/daemon contents:

Nov 21 00:06:05 <hostname> ntpd[7477]: adjusting clock frequency by 0.317142 to -14.304083ppm
Nov 22 02:29:01 <hostname> ntpd[7477]: adjusting clock frequency by 0.305442 to -13.998538ppm
Nov 22 15:27:20 <hostname> ntpd[7477]: adjusting clock frequency by -0.138739 to -14.137278ppm
Nov 23 07:42:51 <hostname> ntpd[7477]: adjusting clock frequency by -0.061709 to -14.198986ppm
Nov 23 15:37:42 <hostname> ntpd[7477]: adjusting clock frequency by -0.303711 to -14.502698ppm
Nov 24 01:57:52 <hostname> ntpd[7477]: adjusting clock frequency by 0.266837 to -14.235861ppm
Nov 24 15:28:31 <hostname> ntpd[7477]: adjusting clock frequency by -0.223563 to -14.459424ppm
Nov 25 05:13:04 <hostname> ntpd[7477]: adjusting clock frequency by -0.223494 to -14.682917ppm
Nov 25 18:10:03 <hostname> ntpd[7477]: adjusting clock frequency by -0.324446 to -15.007363ppm
Nov 26 08:20:06 <hostname> ntpd[7477]: adjusting clock frequency by 0.295603 to -14.711760ppm
Nov 26 20:49:23 <hostname> ntpd[7477]: adjusting clock frequency by 0.517934 to -14.193826ppm
Nov 27 07:56:01 <hostname> ntpd[7477]: adjusting clock frequency by -0.269159 to -14.462985ppm
Nov 27 21:58:31 <hostname> ntpd[7477]: adjusting clock frequency by 0.239882 to -14.223103ppm
Nov 28 07:36:25 <hostname> ntpd[7477]: adjusting clock frequency by -0.435059 to -14.658162ppm
Nov 28 16:34:59 <hostname> ntpd[7477]: adjusting clock frequency by -0.299615 to -14.957777ppm
Nov 29 09:26:36 <hostname> ntpd[7477]: adjusting clock frequency by 0.137505 to -14.820272ppm
Nov 30 14:31:15 <hostname> ntpd[7477]: adjusting clock frequency by -0.215574 to -14.991138ppm
Nov 30 18:27:39 <hostname> ntpd[26935]: ntp engine exiting
Nov 30 18:27:39 <hostname> ntpd[3531]: dispatch_imsg in main: pipe closed
Nov 30 18:27:39 <hostname> ntpd[7477]: Terminating
Nov 30 18:27:55 <hostname> ntpd[27795]: ntp engine ready
Nov 30 18:27:58 <hostname> ntpd[27795]: ntp engine exiting
Nov 30 18:27:58 <hostname> ntpd[30737]: dispatch_imsg in main: pipe closed
Nov 30 18:27:58 <hostname> ntpd[15335]: Terminating
Nov 30 18:27:58 <hostname> ntpd[49555]: ntp engine ready
Nov 30 18:28:21 <hostname> ntpd[49555]: peer 216.239.35.0 now valid
Nov 30 18:28:22 <hostname> ntpd[49555]: peer 216.239.35.4 now valid
Nov 30 18:28:23 <hostname> ntpd[49555]: peer 216.239.35.12 now valid
Nov 30 18:28:24 <hostname> ntpd[49555]: peer 216.239.35.8 now valid
Nov 30 18:30:25 <hostname> ntpd[49555]: clock is now synced
Nov 30 18:40:47 <hostname> ntpd[10865]: ntp engine ready
Nov 30 18:40:47 <hostname> ntpd[36747]: set local clock to Wed Nov 30 18:40:47 CET 2016 (offset 0.000113s)
Nov 30 18:41:07 <hostname> ntpd[10865]: peer 216.239.35.8 now valid
Nov 30 18:41:07 <hostname> ntpd[10865]: peer 216.239.35.4 now valid
Nov 30 18:41:08 <hostname> ntpd[10865]: peer 216.239.35.12 now valid
Nov 30 18:41:09 <hostname> ntpd[10865]: peer 216.239.35.0 now valid
Nov 30 18:44:08 <hostname> ntpd[10865]: clock is now synced
Nov 30 18:48:10 <hostname> ntpd[49555]: ntp engine exiting
Nov 30 18:48:10 <hostname> ntpd[44908]: dispatch_imsg in main: pipe closed
Nov 30 18:48:10 <hostname> ntpd[59920]: Terminating
Nov 30 18:48:10 <hostname> ntpd[57325]: ntp engine ready
Nov 30 18:48:11 <hostname> ntpd[4035]: set local clock to Wed Nov 30 18:48:11 CET 2016 (offset 0.000388s)
Nov 30 18:48:29 <hostname> ntpd[57325]: peer 216.239.35.8 now valid
Nov 30 18:48:32 <hostname> ntpd[57325]: peer 216.239.35.4 now valid
Nov 30 18:48:32 <hostname> ntpd[57325]: peer 216.239.35.0 now valid
Nov 30 18:48:33 <hostname> ntpd[57325]: peer 216.239.35.12 now valid
Nov 30 18:50:57 <hostname> ntpd[53395]: Terminating
Nov 30 18:50:57 <hostname> ntpd[57325]: ntp engine exiting
Nov 30 18:50:57 <hostname> ntpd[26288]: dispatch_imsg in main: pipe closed
Nov 30 18:50:57 <hostname> ntpd[50972]: ntp engine ready
Nov 30 18:50:57 <hostname> ntpd[71389]: set local clock to Wed Nov 30 18:50:57 CET 2016 (offset 0.000046s)
Nov 30 18:51:14 <hostname> ntpd[50972]: peer 216.239.35.0 now valid
Nov 30 18:51:19 <hostname> ntpd[50972]: peer 216.239.35.4 now valid
Nov 30 18:51:21 <hostname> ntpd[50972]: peer 216.239.35.12 now valid
Nov 30 18:51:23 <hostname> ntpd[50972]: peer 216.239.35.8 now valid
Nov 30 18:53:46 <hostname> ntpd[46409]: ntp engine ready
Nov 30 18:53:47 <hostname> ntpd[51869]: set local clock to Wed Nov 30 18:53:47 CET 2016 (offset 0.017304s)
Nov 30 18:54:05 <hostname> ntpd[46409]: peer 216.239.35.0 now valid
Nov 30 18:54:06 <hostname> ntpd[46409]: peer 216.239.35.4 now valid
Nov 30 18:54:08 <hostname> ntpd[46409]: peer 216.239.35.8 now valid
Nov 30 18:54:08 <hostname> ntpd[46409]: peer 216.239.35.12 now valid
Nov 30 18:57:13 <hostname> ntpd[46409]: clock is now synced
Nov 30 19:15:19 <hostname> ntpd[43240]: adjusting clock frequency by 0.420934 to -14.570066ppm
Nov 30 19:34:26 <hostname> ntpd[43240]: adjusting clock frequency by 0.080845 to -14.489222ppm
Nov 30 19:53:41 <hostname> ntpd[43240]: adjusting clock frequency by -0.092990 to -14.582212ppm
Dec  1 16:56:15 <hostname> ntpd[43240]: Terminating
Dec  1 16:56:15 <hostname> ntpd[46409]: ntp engine exiting
Dec  1 16:56:15 <hostname> ntpd[59696]: dispatch_imsg in main: pipe closed
Dec  1 16:56:15 <hostname> ntpd[61779]: ntp engine ready
Dec  1 16:56:15 <hostname> ntpd[64211]: set local clock to Thu Dec  1 16:56:15 CET 2016 (offset 0.000150s)
Dec  1 16:56:16 <hostname> ntpd[61779]: ntp engine exiting
Dec  1 16:56:16 <hostname> ntpd[76241]: Terminating
Dec  1 16:56:16 <hostname> ntpd[48763]: dispatch_imsg in main: pipe closed
Dec  1 16:56:16 <hostname> ntpd[19408]: ntp engine ready
Dec  1 16:56:16 <hostname> ntpd[89788]: set local clock to Thu Dec  1 16:56:16 CET 2016 (offset 0.000336s)
Dec  1 16:56:35 <hostname> ntpd[19408]: peer 216.239.35.8 now valid
Dec  1 16:56:36 <hostname> ntpd[19408]: peer 216.239.35.12 now valid
Dec  1 16:56:38 <hostname> ntpd[19408]: peer 216.239.35.4 now valid
Dec  1 16:56:38 <hostname> ntpd[19408]: peer 216.239.35.0 now valid
Dec  1 17:00:49 <hostname> ntpd[19408]: clock is now synced
Dec  1 17:22:51 <hostname> ntpd[68037]: adjusting clock frequency by -0.076636 to -14.641308ppm

The start/stop etc. is me testing/trying stuff.

3
  • 1
    Is the server a VM?
    – Rui F Ribeiro
    Dec 1, 2016 at 17:02
  • Oh, crap. I meant to mention that in the question but forgot during posting all the other information. Yes, yes it is. Running on ESXi 6. The other Debian machines (guests) are, however, also running on the same host. I'll edit the information in the question. I apologize for omitting that.
    – RobIII
    Dec 1, 2016 at 17:19
  • No, sorry. I never install the vmtools stuff. I just checked, no open-vm-tools nor antyhing named vmware or vm to be found.
    – RobIII
    Dec 1, 2016 at 19:10

3 Answers 3

Reset to default
14

OpenBSD and your VM are working right; you are mis-using the Google time source.

This is in the OpenBSD Frequently Asked Questions and manual pages.

You are synchronizing to a time source that publishes UTC time, sort of. But by default rdate assumes that your time source publishes TAI-10 time. TAI, a strict uniformly increasing count of all SI seconds with always 60 seconds per minute, is currently 36 seconds ahead of UTC, which occasionally discounts so-called "leap seconds". (More accurately: It discounts positive leap seconds; but there hasn't actually been a negative leap second yet.) It will become 37 seconds ahead of UTC at 2016-12-31 23:59:60 UTC, the leap second coming up at the end of this month.

Systems that use TAI rather than UTC actually tend to use what is more accurately known as TAI-10, which is the TAI count shifted into the future by 10 so that it aligns 1970-01-01 00:00:00 UTC, also known as 1969-12-31 23:59:50 TAI, with 1970-01-01 00:00:00 TAI-10.1 This is 26 seconds ahead of UTC, soon to become 27.

Famously, the Google time sources do not count leap seconds. They use smearing which spreads the value of the uncounted extra second across an entire day, and which means that for up to two days per year Google seconds are not a uniform length and are not the same length as an SI second.

rdate needs the -c option to tell it that your time source does not count leap seconds, and you need to use an Olsen "right" timezone that assumes that your kernel clock runs in TAI-10. ("right" timezones and a kernel clock that counts TAI instead of UTC have their advantages.)

Ironically, since you are, too, using Central European Time according to your logs, the example settings given in the OpenBSD Frequently Asked Questions are exactly the ones for you. So read the OpenBSD doco and follow the instructions.

Or: If you want to run in UTC rather than TAI-10, use the "posix" timezones.

1 This is a slightly simplified explanation that involves a commonly used retroactive definition of UTC, and ignores the fact that the UT seconds used before 1972 were variable-length with large table-driven algorithms for converting to/from TAI. But that is beyond the scope of this answer. The situation before 1972 was horrendous. Some people want to do away with UTC and its leap second system and SI second length, and bring that back. They are … misguided.

Further reading

2
  • Thanks! This was it. I have no idea why I didn't find that section in the FAQ... I ran cd /etc && ln -sf /usr/share/zoneinfo/right/CET localtime and rdate -ncv time.google.com and now my date/time is correct. Thank you so much for your answer and (thorough) explanation!
    – RobIII
    Dec 1, 2016 at 20:32
  • Neat! I never knew this (I’ve never had my time off my twenty-some seconds either, but interesting nonetheless).
    – Bink
    Dec 2, 2016 at 21:02
3

26 is a magic number, it is (today) the number of leap seconds added to UTC.

Are you comparing the OpenBSD time with a Debian system which has the "right" zoneinfo files?

TZ=/usr/share/zoneinfo/right/GB-Eire date; date
Thu Dec  1 19:46:16 GMT 2016
Thu Dec  1 19:46:41 GMT 2016

(apologies, I'm only 25 seconds out since I haven't updated my tzdata to account for last year's leap)

The origins of this lie in strict POSIX interpretations of time, of which you can read more here: http://www.ucolick.org/~sla/leapsecs/timescales.html

1
  • Thanks for the (also correct) answer you posted. I accepted JdeBP's answer because it's more thorough but I appreciate you taking the time and answering too!
    – RobIII
    Dec 1, 2016 at 20:53
1

While it’s been a while since I ran OpenBSD under VMware, if your VM host has the correct time, you might want to try using OpenBSD’s built-in VMware Tools driver, vmt(4), as a sensor for ntpd(8) instead of the time servers. If that doesn’t work, you can try, additionally, setting kern.timecounter.hardware=acpitimer0 via sysctl(8).

Posting the output from ntpd in /var/log/daemon might be helpful as well.

1
  • I edditted the contents of /var/log/daemon into the question. I'll look into your suggestions as soon as I have more than 5 minutes of time. Thanks so far!
    – RobIII
    Dec 1, 2016 at 19:14

You must log in to answer this question.

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