Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
    
Post your /etc/ntp.conf. –  Michael Hampton Nov 15 '12 at 22:52
    
ntp.conf is the stock debian squeeze config: cs.uwaterloo.ca/cscf/software/ntp/etc/ntp.conf –  David Wolever Nov 15 '12 at 22:54

2 Answers 2

up vote 7 down vote accepted

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.

share|improve this answer

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

share|improve this answer
1  
Unfortunately this does not help in situations which depend on the time of day =\ –  David Wolever Nov 15 '12 at 23:06
2  
Asker didn't find it helpful for this particular instance, but +1 for good general knowledge. –  Jeff Ferland Nov 15 '12 at 23:08

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.