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 220.127.116.11 2 u 451 1024 377 36.824 18621.8 18622.1 ntp.newfxlabs.c 18.104.22.168 2 u 25 1024 377 69.693 18623.6 17241.1 time.tritn.com 22.214.171.124 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