0

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??

Raul Andres
  • 3,766
  • 15
  • 24
user3034773
  • 27
  • 1
  • 3
  • "changes are not immediately reflected in PC2.". But are they reflected after some timep period? – Raul Andres May 30 '14 at 09:31
  • Yes, after sometime when I type date command, I can see the change. But that takes around 8-10 minutes. Any method to see immediate change on PC2? That too automatized? – user3034773 May 30 '14 at 10:00
  • Please do not set the system to stratum 1. PC2 will not reject pc1 if you set the stratum to 6. It is bad practice to fake a stratum one in case the machine is ever connected to the internet. Furthermore you do not need to set the stratum on pc2 manually. It will be n+1 where n is the stratum of pc1. Setting the stratum on pc1 to 6 or higher is a good choice and will not have an effect on time performance. – dfc May 30 '14 at 19:22

2 Answers2

2

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.

Anya Shenanigans
  • 91,618
  • 3
  • 107
  • 122
  • Keeping two systems clocks in sync with each other is dingdangdifficult, and most algorithms assume that you're **not** actively adjusting one of the clocks. Once you eliminate that source of issues, NTP and it's newer cousin PTP will help keep your clocks in sync with a reasonable degree of accuracy. – Anya Shenanigans May 30 '14 at 10:49
1

Your question implies that you are expecting pc2 to quickly determine that the time has changed on pc1, and update accordingly, is that the behaviour you are looking for? If so, I don't think ntp by itself will really do that as ntp doesn't really expect the server to be changing its time

You could also try using ntpdate -s to set the time immediately.

Jason Lewis
  • 147
  • 11
  • I think you need to explain your end goal a little further. Without some context it's hard to suggest a good solution. – Jason Lewis May 30 '14 at 10:26