Force ntpd to make changes in smaller steps

The NTP documentation says:

Under ordinariy conditions, ntpd adjusts the clock in small steps so that the timescale is effectively continuous and without discontinuities - http://doc.ntp.org/4.1.0/ntpd.htm

However, this is not at all what I have noticed in practice. If I manually change the system time backwards or forwards 5 or 10 seconds then start ntpd, I notice that it adjusts the clock in one shot.

For example, with this code:

#!/usr/bin/env python
import time
last = time.time()
while True:
    time.sleep(1)
    print time.time() - last
    last = time.time()

When I first change the time, I'll notice something like:

1.00194311142
8.29711604118
1.0010509491

Then when I start NTPd, I'll see something like:

1.00194311142
-8.117301941
1.0010509491

Is there any way to force ntpd to make the adjustments in smaller steps?

Solution 1:

Passing ntpd -x when starting the daemon will keep changes very small: there will be no stepping of the clock. Of course, setting slewing only means it may take a while to correct for larger gaps if you start with your clock very far off the correct time. Quoting a few paragraphs from the man page

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.

Since you adjusted your clock by 10 seconds, you definitely exceeded the realm of what NTP was expecting to see, thus the stepping.

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.

Running ntpdate before starting major services and then running ntpd -x after that may be a good combined solution to make sure any major steps happen before step-less timekeeping is needed.

Solution 2:

If this is for code you want to write, this may be the answer you're looking for: https://stackoverflow.com/questions/1205722/how-do-i-get-monotonic-time-durations-in-python