Wednesday 23 April, 2008 - 10:44
I think I may have solved the NTP problem by following the procedure in Dyle and Shaw (2006) pp.261-2:
# vi /etc/ntp.conf
restrict 192.168.100.97 mask 255.255.255.255 nomodify notrap noquery
# service ntpd restart
Shutting down ntpd: [ OK ]
ntpd: Synchronizing with time server: [ OK ]
Starting ntpd: [ OK ]
# date
Wed Apr 23 09:43:02 EST 2008
The line highlighted is the important difference. NTP daemon was not synchronising with the clock server on central (192.168.100.97).
This change was brought about by adding the restrict statement to /etc/ntp.conf. The effect is to force the local server to look to central as the master clock instead of itself. nomodify means that the server will not try to update the master. notrap ?. noquery means that the master clock cannot query this server for the time.
/var/log/messages shows:
step time server 192.168.100.97 offset 21.012986 sec
From my reading of info ntpd, the ntp step timer should gradually converge the local clock to the master with adjustments occurring about every minute.
Unfortunately, I see the clocks diverging. This could be caused by VMware scheduling the virtual CPUs under Vista scheduling algorithm.
The recommendation at [ntp:questions] Re: step-tickers is to start ntpd with the -g option.
The options are changed in /etc/sysconfig/ntpd. I added the -g option to the file and restarted the ntpd.
The clocks are synchronised straight away but they still drift quite quickly (1 minute slow over a 2 minute period). NTP could not work with VMware.