wall clock seriousely broken (27 seconds bug)

[PMc]

There is a problem with the ntp.

One machine is connected to the internet, and is nicely synced:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+syrte8.obspm.fr 145.238.203.14   2 u   61   64  377   33.965   -2.064   0.406
-schnitzel.team  193.67.79.202    2 u   60   64  377   31.615   -1.229  31.308
-mail.stygium.ne 129.69.1.153     2 u   58   64  377   22.620   -0.202   0.688
-ns02.hoberg.ch  130.149.17.21    2 u   61   64  377   27.105   -1.164   0.804
-stratum2-4.NTP. 129.70.130.70    2 u   60   64  377   35.949    2.076  10.691
-formularfetisch 192.53.103.108   2 u   56   64  377   37.536   -6.071  19.475
+time3.hs-augsbu 192.53.103.103   2 u   53   64  377   33.041   -1.376   0.954
*atlas.linocomm. 130.149.17.21    2 u   49   64  377   36.727   -4.250   0.666

So one should assume that we have a time that is about 5ms correct.

The other machine is attached to this one, and is also synced:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*xxxxxxxxxxxxxxx 145.238.203.10   3 u  940 1024  377    0.557   -0.733   0.631

This second machine shows the (assumed) correct time.
But the first machine shows a time that is 27 seconds off!

And there are no error messages whatsoever.

The thing I found is this: https://serverfault.com/questions/943989/ntp-27-seconds-difference

What is obvious, is, there are exactly 27 leap seconds between the epoch and today.

So I do the following:

1. I shut down all ntpd. Clocks still differ by 27 seconds.
2. I check both machines with ntpdate -q against the same respectable stratum-1 server.
3. Both say they are within 1ms. Clocks still differ by 27 seconds.

This is unacceptable.

 

[derekschrock]

Sounds like you're hitting an NTP server that's giving out Loran-C time scale? http://leapsecond.com/java/gpsclock.htm

Assuming you have DNS and access to the Internet via NTP what does the following command output?

ntpdate -q pool.ntp.org

We had someone configure a local GPS based NTP server to serve GPS time scale because..."it's GPS." After they reconfigured that we were no longer 18 seconds off UTC.

 

[PMc]

No, it's independent of ntp, and it doesnt matter which NTP server. Time is always correct within milliseconds no matter if its 27 seconds more or less.

$ date; ssh edge-e1 date ; ntpdate -q pool.ntp.org ; ssh edge-e1 ntpdate -q pool.ntp.org ; date ; ssh edge-e1 date
Sun Feb 17 05:00:27 CET 2019
Sun Feb 17 05:00:01 CET 2019
server 185.120.22.12, stratum 2, offset -0.001620, delay 0.05005
server 212.18.3.18, stratum 2, offset -0.002111, delay 0.05283
server 178.63.9.212, stratum 2, offset -0.008108, delay 0.06413
server 85.114.128.137, stratum 2, offset -0.001046, delay 0.05103
17 Feb 05:00:35 ntpdate[55276]: adjust time server 185.120.22.12 offset -0.001620 sec
server 129.70.132.37, stratum 2, offset -0.000170, delay 0.05841
server 85.114.128.137, stratum 2, offset -0.001139, delay 0.05124
server 5.9.83.106, stratum 2, offset -0.005646, delay 0.06407
server 217.91.44.17, stratum 2, offset -0.001543, delay 0.05942
17 Feb 05:00:17 ntpdate[56328]: adjust time server 85.114.128.137 offset -0.001139 sec
Sun Feb 17 05:00:44 CET 2019
Sun Feb 17 05:00:17 CET 2019

I might assume somewhere might be a switch to decide if the wallclock should add the leapseconds nor not - but I do not remember ever having seen such switch, even less flipping it.

 

[derekschrock]

Maybe ntp on one is slewing towards the correct time? I don't know if ntpdate knows if ntpd is slewing or not.

Can you force ntpdate to step the time via -b. This should be happening if it's greater than 128ms but -b just to force it.

Also, are you running ntpd with -g the rc.conf setting is ntpd_sync_on_start that will do the same thing as ntpdate but not use ntpdate.

 

[PMc]

Its not the NTP. NTP is in the firm opinion that it is on correct time.

No, its the timezone database!

$ date ; TZ=UTC date
Sun Feb 17 05:35:27 CET 2019
Sun Feb 17 04:35:54 UTC 2019
/etc # rm localtime
/etc # ln -s /usr/share/zoneinfo/Europe/Berlin localtime
$ date ; TZ=UTC date
Sun Feb 17 05:37:00 CET 2019
Sun Feb 17 04:37:00 UTC 2019

Yeah, I didn't do nothing - meaning, when experimenting with this matter, at some point the installer had replaced that localtime symlink with a real file, copied from whereever.

We learn: there is a way to make FreeBSD issue Loran time.