4

I'm using SNTP to sync my Debian based system. SNTP has two ways to set the clock:

-s, --settod     Set (step) the time with settimeofday().
-j, --adjtime    Set (slew) the time with adjtime().

The slew method adjusts the local system clock in small steps until the detected offset is zero. Slewing is primarily done to not upset processes that react badly to a clock gone backwards in time.

The step method sets the clock instantly.

With regards to the slewing of time, how long could SNTP take to complete this?

Is there a way to poll the system and give me feedback that a slew is still in progress?

  • If you can write a C program you can use the adjtime() system call to get the kernel to report how much clock slew is left to be done. – Kyle Jones Jan 19 '15 at 5:00
2

The step method sets the clock instantly. How long could SNTP take to complete slewing?

I am not experienced with SNTP solutions, so assume they are not different from full-fledged NTP in this regard. As for the former, it uses two turnkey limits: 128 ms for stepping and 500 ppm (496 to 512 ppm) for locking and slewing. That means that the maximum allowed offset of 128 ms will be compensated at maximum slewing rate of 512 ppm in a matter of 250 seconds (4.17 minutes). In practice, however, this will probably take slightly longer, as slewing rate is gradually decreased when approaching the target time — down to the computed regular correction rate.

Is there a way to poll the system and give me feedback that a slew is still in progress?

Try the stock ntptime utility: it queries the kernel directly, and works even when ntpd is not running. That is, of course, provided that adjtime() calls ntp_adjtime() internally, which I am not sure of.

1
man adjtime

.
.
.

If the adjustment in delta  is  positive,  then  the  system  clock  is
speeded  up by some small percentage (i.e., by adding a small amount of
time to the clock value in each second) until the adjustment  has  been
completed.   If  the adjustment in delta is negative, then the clock is
slowed down in a similar fashion.

So the kernel will manage the time adjustment every second, and the size of the adjustment is dependent on the size of values passed in the struct passed to the adjtime(3) call. A point of interest is that Linux uses adjtimex(3) which is based on RFC1305 (NTP version 3), and section 5 goes into the gritty details of how this time skew is managed.

  • I'm also using adjtimex to compensate for a systematic drift of the local clock inbetween ntp syncs, but I'm still not sure that when I do a sync and the difference is off by, say 5 seconds, how long it will take for those 5 seconds to have been slewed to the correct time. Thanks for pointing out the RFC. – captcha Jan 19 '15 at 21:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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