How long will NTP take to adjust the clock if it doesn't immediately set it? 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?

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

I am not experienced with **S** NTP 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.