# wall clock seriousely broken (27 seconds bug)



## PMc (Feb 17, 2019)

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: 

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


----------



## derekschrock (Feb 17, 2019)

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 (Feb 17, 2019)

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 (Feb 17, 2019)

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 (Feb 17, 2019)

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.


----------

