linuxrhelntpd

Instantaneous synchronization using NTP


I am working with two PCs: PC1 (server) and PC2 (client) and I am trying to synchronize their time with NTP. PC1 is not configured to get synchronized with any external time source. I just want whatever time is there on the PC1, PC2 should be synchronized in accordance to that. I've done following changes-:

In PC1 (server)-:

#vi /etc/ntp.conf
server 127.127.1.0
fudge 127.127.1.0 stratum 1
restrict 127.0.0.1
restrict 192.168.50.0 mask 255.255.255.0 nomodify notrap
driftfile /var/lib/ntp/drift
:wq!

#vi /etc/ntp/step-tickers
# List of servers used for initial synchronization.
127.127.1.0
:wq!

#vi /etc/init/rc.conf
ntpd_enable=\"YES\"
:wq!

In PC2 (client)-:

#vi /etc/ntp.conf
server 192.168.50.201
fudge 127.127.1.0 stratum 2
restrict 127.0.0.1
driftfile /var/lib/ntp/drift
restrict 192.168.50.201 mask 255.255.255.255 notrap nomodify
:wq!

#vi /etc/ntp/step-tickers
192.168.50.201
:wq!

#crontab -e
1 * * * * ntpdate -s -b -u 192.168.50.201
:wq!

#vi /etc/init/rc.conf
ntpd_enable=\"YES\"
:wq!

I've also changed the firewall settings at both sides by adding these lines-:

#vi /etc/sysconfig/iptables
-I INPUT -p udp --dport 123 -j ACCEPT
-I OUTPUT -p udp --sport 123 -j ACCEPT
:wq!

However, I am not able to synchronize PC2 date with PC1 date i.e. when I change date in PC1, changes are not immediately reflected in PC2. I am using RHEL 6.2 .

Can anyone tell me where I am going wrong??


Solution

  • The central algorithm of NTP is intended to synchronize clocks and keep them in sync over long periods of time; not to keep two clocks in lock-step when one changes in relation to the other.

    It's designed to work on internet scale, not on a local network scale.

    In order to do this, it gets initial times from the NTP server that it's connected to and uses it to determine the difference between the local time and the server time. This is then turned into a slope of a curve that is used to adjust the local clock to match the server clock and to keep them in sync with each other.

    This slope is adjusted by polling the remote server on a continual basis. The interval between the polls of the remote server are configured using the minpoll and maxpoll intervals. Those intervals are defined as the power-of-two number of seconds between polls (and bear in mind that those poll intervals are not strict times, it has randomness added to prevent request floods in the event of a large number of servers starting up at the same time). The default poll interval is minpoll = 6 (== 64seconds), maxpoll = 10 (== 1024seconds).

    What happens is the first poll takes place, then the second is 64 seconds later, as more samples are obtained from the server, this interval moves out, assuming that the model of the local clock and remote clocks remain relatively stable i.e. as more time passes, the rate of polling can decrease as the model has been determined.

    If you adjust the clock on the server then the model needs to be recalculated. This will take some time as the algorithm will take into account previous time differences in determining the current expected difference.

    If you set the minpoll and maxpoll for the server to 4, then it will poll the server roughly once every 16 seconds, which will accelerate the adjustment of the clock model, but it will still take time for the clocks to get in sync with each other. This is a useful setting to perform when running in a LAN environment where you're polling a relatively close server.

    running ntpd is signing up to long-term stability of your clock, running ntpdate is signing up to periods of time where you clock is in sync with a remote server, at all other times your clock will get out-of sync with the remote time as it's not got a model from which to adjust the local time to keep it up to date with the remote server.

    You can't run ntpdate while ntpd is running unless you use the -u flag, which causes it to not use the default ntp port of 123. Otherwise you get the the NTP socket is in use, exiting message.