What does "ntpd -x" mean? Can I run ntpd in slew mode?

Solution Verified - Updated

Environment

  • Red Hat Enterprise Linux 5
  • Red Hat Enterprise Linux 6
  • Red Hat Enterprise Linux 7
  • ntp
  • slew mode (-x)

Issue

  • What does "ntpd -x" mean?
  • I see -x in the OPTIONS directive in the /etc/sysconfig/ntpd file.
  • What is slew mode?
  • Is there any disadvantage?
  • As we know the ntpd slew mode 'protect' OS against leapsecond so why do not use it always? Can you see disadvantages of such a setup?

Resolution

Normally, the time is slewed (gradually adjusted) if the offset is less than the step threshold, which is 128 ms by default, and stepped (time jump) if above the threshold.
The -x option, also called slew mode, sets the threshold to 600s.

It is also important to understand that your hardware has to be able to keep relatively good time, that part is sometimes an issue. Note that the frequency of the clock can change due to the aging of the crystal, differences in calibration of the clock source between reboots, migrated virtual machine, etc. A typical computer clock has a drift smaller than 100 parts per million (ppm), but much larger drifts are possible (e.g. in some virtual machines).
Every second to correct takes over a half-hour (2000s) to actually correct in slew mode.
It also disables the kernel discipline, which can usually synchronize clocks with better accuracy, and kernel 11-minute mode, which automatically synchronizes the hardware clock to the system clock. Please see hwclock(8) man page for more details of 11-minutes mode and see here if you want to check whether it is working.

As a recommended alternative, the stepping threshold can be increased to just 0.5s and not 600s to keep the kernel discipline and 11-minute mode enable.
This is done using the tinker directive. Instead of adding "-x" in /etc/sysconfig/ntpd, we suggest adding this line in /etc/ntp.conf:

tinker step 0.5

and then restart the ntpd service.
RHEL 5 and RHEL6:

# service ntpd restart

RHEL7:

# systemctl restart ntpd

Root Cause

  • From ntpd man page:
"-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. See the tinker command  for other
options. Note: The kernel time discipline is disabled with this
option.

Under  ordinary  conditions,  ntpd  adjusts  the clock in small steps so that the timescale is effectively continuous and without discontinuities. Under conditions of extreme network congestion, the roundtrip delay jitter can exceed three seconds and the synchronization distance, which is equal to one-half the roundtrip delay plus error budget terms, can become very large. The ntpd algorithms discard sample offsets exceeding 128 ms, unless the interval during which no sample  offset  is  less  than  128  ms exceeds 900s. The first sample after that, no matter what the offset, steps the clock to the indicated time. In practice this reduces the false alarm rate where the clock is stepped in error to  a  vanishingly  low incidence.

As  the  result of this behavior, once the clock has been set, it very rarely strays more than 128 ms, even under extreme cases of network path congestion and jitter. Sometimes, in particular when ntpd is first started, the error might  exceed 128 ms. This may on occasion cause the clock to be set backwards if the local clock time is more than 128 s in the future relative to the server. In some applications, this behavior may be unacceptable. If the -x option is included on the command line, the clock will never be stepped and only slew corrections will be used. 

The  issues  should be carefully explored before deciding to use the -x option. The maximum slew rate possible is limited to 500 parts-per-million (PPM) as a consequence of the correctness principles on which the  NTP  protocol  and  algorithm design  are  based.  As a result, the local clock can take a long time to converge to an acceptable offset, about 2,000 s for each second the clock is outside the acceptable range. During this interval the local clock will  not  be  consistent with  any  other network clock and the system cannot be used for distributed applications that require correctly synchronized network time.

In spite of the above precautions, sometimes when large frequency errors are present the  resulting  time  offsets  stray outside  the  128-ms  range  and an eventual step or slew time correction is required. If following such a correction the frequency error is so large that the first sample is outside the acceptable range, ntpd enters the same state as when the ntp.drift  file  is not present. The intent of this behavior is to quickly correct the frequency and restore operation to the normal tracking mode. In the most extreme cases, there may be occasional  step/slew  corrections  and  subsequent  frequency  corrections.  It helps in these cases to use the burst keyword when configuring the server.
SBR
Product(s)
Components
Category
Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.