A well-behaved NTP implementation will generally slew the clock, once the initial set is made. Jumps in time are generally detrimental. Jumps backward in time can be disasterous. The slew rate is typically limited to 500 ppm. Note that a "good" NTP implementation will estimate the frequency of the device's internal clock and "continually" apply corrections.
adjtime or similar often handles this slew within the kernel itself.
adjtime -- correct the time to allow synchronization of the system clock
adjtime(const struct timeval *delta, struct timeval *olddelta);
adjtime() makes small adjustments to the system time, as returned by gettimeofday(2), advancing or retarding it by the time specified by the timeval delta.
If delta is negative, the clock is slowed down by incrementing it more slowly than normal until the correction is complete. If delta is positive, a larger
increment than normal is used. The skew used to perform the correction is generally a fraction of one percent. Thus, the time is always a monotonically
increasing function. A time correction from an earlier call to adjtime() may not be finished when adjtime() is called again. If olddelta is non-nil, the
structure pointed to will contain, upon return, the number of microseconds still to be corrected from the earlier call.
Edit: At least for my OpenWrt boxes, very little happens that needs device-to-device synchronization much better than a second or so. There are only a couple things I can think of that happen faster that I need 100-ms or better device-to-device synchronization. Two that come to mind would be:
- Examining STP topology-change speed
- Examining 802.11r roaming speed
An hour in now, my OpenWrt box is polling "public pool" servers at 256 seconds and is within 3 ms of my "good" NTP server (which it is not using as a peer).
Two hours in now, the poll time appears to 512 seconds and is still within 3 ms of my reference.