2

I have two debian wheezy machines on the same LAN that have clocks synchronized using NTP. Using date I see that the times are synchronized. I then set the time back about 30 seconds using date --set on one of the machines.

When will the ntp service correct the clock? It's been about 15 minutes and the two machines still have a 30 second difference in the output of date. I know I can force a clock update, but I want to know how quickly the ntp service will update the clock automatically.

Here`s some status:

root@unassigned-hostname:# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 materialinmotio .CDMA.           1 u  621 1024  377   78.039  18621.9 18622.5
 hadb2.smatwebde 200.98.196.212   2 u  451 1024  377   36.824  18621.8 18622.1
 ntp.newfxlabs.c 216.218.192.202  2 u   25 1024  377   69.693  18623.6 17241.1
 time.tritn.com  216.218.192.202  2 u  284 1024  377   69.584    0.466 7038.56
root@unassigned-hostname:# service ntp status
NTP server is running.

and my /etc/ntp.conf:

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntp/ntp.drift


# Enable this if you want statistics to be logged.
#statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable


# You do need to talk to an NTP server or two (or three).
#server ntp.your-provider.example

# pool.ntp.org maps to about 1000 low-stratum NTP servers.  Your server will
# pick a different set every time it starts up.  Please consider joining the
# pool: <http://www.pool.ntp.org/join.html>
server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst


# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details.  The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>
# might also be helpful.
#
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.

# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust


# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
#broadcast 192.168.123.255

# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines.  Please do this only if you trust everybody on the network!
#disable auth
#broadcastclient
awelkie
  • 141

1 Answers1

4

The client you have shown is not synchronised to any server (there's no * marker in the first column). All were solidly reachable over the previous attempts (reach = 377, the maximum value). However, the daemon will check only every 1024 seconds (poll interval) because it was either configured that was or the client's time has been stable, and you're at best still 400 seconds away from that (when = 621).

When the client discovers the time is wildly wrong it will start to slew the time back to the correct value. If you're lucky it will also drop the poll interval back to the starting value so that it can safely synchronise more quickly.

I've just tried stepping the time back on a spare box here. I see that my system's still synchronised to its upstream (* in first column) but the offset has gone to 30004.6 (i.e. 30 seconds) and the jitter has increased to 30000.3. The poll time hasn't reduced so it's going to take at least one more 1024 second cycle to realise it's slipped through a timewarp.

ntpq -pn                                                                                        

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+5.196.160.139   145.238.203.14   2 u  211 1024  377    0.879  30004.6 30000.3
*195.154.79.192  222.217.153.8    2 u  607 1024  377    5.140   -0.937   1.479
+91.134.209.213  149.202.97.123   3 u  452 1024  377    0.848   -0.540   1.604
-10.20.3.131     163.172.28.46    4 u  901 1024  376    7.189    0.395   0.954

Now, a couple of hours later, my system has caught up again:

ntpq -pn                                                                                       

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*5.196.160.139   145.238.203.14   2 u  432 1024    7    0.755    1.954   0.049
+195.154.79.192  222.217.153.8    2 u  557 1024    1    4.955   -1.616   0.015
+91.134.209.213  149.202.97.123   3 u  429 1024    7    0.754   -0.328   0.125
 10.20.3.131     163.172.28.46    4 u  174 1024    3    7.023   -0.991   1.023
Chris Davies
  • 116,213
  • 16
  • 160
  • 287
  • It's definitely been over 1024 seconds since I set the time. What could cause a synchronization to fail? I'm assuming ntpd tried to synchronize and failed because there's still no * in the first column. Also, how fast will the clock slew? Will this take a few seconds, a few minutes, hours? – awelkie Jan 13 '17 at 14:34
  • In your answer here, you claim that causing a discrete jump in the clock while ntp is running will make ntp fail and the only solution is to restart the ntp service. Could that be the case here? I set the clock back 30 seconds while ntp was running. – awelkie Jan 13 '17 at 14:50
  • 1
    @awelkie If NTP slews the time it will take about 2000 seconds to correct 1 second. NTP has a maximum slew rate of 500 PPM. If the clock is more than 128 milliseconds off when starting ntpd, it will step the time instead. – Kusalananda Jan 13 '17 at 14:51
  • @awelkie NTP will cope with a jump of 30 seconds. I assumed that you were testing rather than, as in the other question, deliberately trying to (re)set the time on a frequent basis. Different question → different assumptions and different answer :-) – Chris Davies Jan 13 '17 at 14:54
  • @Kusalananda maybe it's just a slow slewing that I'm experiencing. It's been about an hour since I set the clock, which according to your numbers would only allow for a correction of 1.8 seconds. I didn't measure the time difference at the start accurately enough to know whether it's been improved by 1.8 seconds yet. – awelkie Jan 13 '17 at 14:57
  • @awelkie Reference for my previous comment is http://doc.ntp.org/4.1.0/ntpd.htm – Kusalananda Jan 13 '17 at 14:58