Enable NTP with clock slewing on RHEL6

by bzinger   Last Updated May 03, 2017 14:00 PM

I have a RHEL6 server running an Oracle database. When the server was built, NTP wasn't enabled or configured. My task is to do that without impacting the database. After doing some research, I was under the assumption that, when enabling NTP on RHEL6, the time would drift until it was in sync. However, when I did this on my test machine, the system clocked immediately jumped to the NTP time. The time was approximately 2 1/2 minutes off before enabling NTP. When I ran the ntpstat command, it was unsynchronized for a little while but is now in sync.

So, how do I enable NTP and have it drift into the correct time instead of "brute-forcing" it into sync? Thanks for your help!!

[[email protected] etc]# service ntpd status
ntpd is stopped
[[email protected] etc]#
[[email protected] etc]# ntpdate -q time.mydomain.com
server 1.1.1.1, stratum 2, offset 154.573234, delay 0.02890
 2 May 15:47:59 ntpdate[21584]: step time server 1.1.1.1 offset 154.573234 sec
[[email protected] etc]#
[[email protected] etc]# service ntpd start
Starting ntpd:                                             [  OK  ]
[[email protected] etc]# ntpdate -q time.mydomain.com
server 1.1.1.1, stratum 2, offset -0.000118, delay 0.02876 
 2 May 15:50:47 ntpdate[21606]: adjust time server 1.1.1.1 offset -0.000118 sec
[[email protected] etc]# date
Tue May  2 15:51:01 EDT 2017
[[email protected] etc]# ntpstat
unsynchronised
polling server every 64 s
[[email protected] etc]# ntpstat
synchronised to NTP server (1.1.1.1) at stratum 3
 time correct to within 80 ms
 polling server every 1024 s
Tags : ntp rhel6 ntpd


Answers 1


NTPD can adjust your clock in slow increments if it's off, clock slewing. The idea behind that is that slow steps won't cause issues with software timers, strange gaps in log files and your data etc.

The maximum slew rate possible is limited to 500 parts-per-million (PPM) by the Unix kernel. As a result, the clock can take 2000s for each second the clock is outside the acceptable range.

According to the manual page ntpd won't work if your clock is more then 1000 seconds off. (Although you can tune that with the -g switch slowly compensating a 1000 second offset will already take more than 3 weeks.)

Second the time jump you observed when you started ntpd is the result of the default ntpd behaviour to step rather than slew the clock when the offset is greater than 128 ms when ntpd starts up. That makes sense when ntpd is started at boot but not quite what you want on a running system.

You can prevent that by adding the -x switch to the start-up options for ntpd. From the manual:

-x
Normally, the time is slewed if the offset is less than the step threshold, which is 128 ms by default, and stepped if above the threshold. This option sets the threshold to 600 s, which is well within the accuracy window to set the clock manually. Note: Since the slew rate of typical Unix kernels is limited to 0.5 ms/s, each second of adjustment requires an amortization interval of 2000 s Thus, an adjustment as much as 600 s will take almost 14 days to complete. This option can be used with the -g and -q options

In RHEL systems that would be adjusted the in /etc/sysconfig/ntpd config file before starting the ntpd service:

# /etc/sysconfig/ntpd
# Drop root to id 'ntp:ntp' by default.
OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid -g -x" 
HBruijn
HBruijn
May 03, 2017 13:28 PM

Related Questions


ntpd: servers stuck on .INIT

Updated May 02, 2015 21:00 PM

NTP Server peering

Updated October 10, 2015 07:00 AM

Things to consider when running public NTP servers

Updated February 25, 2017 02:00 AM