I’ve used Linux on an embedded system which gets time/date via proprietary monitoring protocol. Seting Linux time/date isn’t instant, Linux will run an accelerated clock until it reaches the target time. This bizzare behaviour is a hack to fix apps/services which have too high delta time which cause other problems. Its frustrating for us since when we receive a clock update, our clocks can take hours to sync. Meanwhile our packet clocks are inaccurate. This only happens during testing (by gov regulators) and to pass the tests, we had to outsmart the way the system clock works when receiving a large date/time diff.
All of these work-arounds for unneeded hacks (like in the article) drives my temper way up. Just do the simple thing in kernel space or the OS level. No suprises.
NTP will step the clock instead of slewing it if the offset exceeds a threshold, your proprietary algorithm should do the same if the time to adjust the clock is too long. I don’t think it’s unreasonable for apps to assume that time is continuous and always moving forward, so slewing seems like a good solution to the problem of time synchronization, if you need instant synchronization you can always step the clock yourself.
Under ordinary conditions, the clock discipline gradually slews the clock to the correct time, so that the time is effectively continuous and never stepped forward or backward. If, due to extreme network congestion, an offset spike exceeds the step threshold, by default 128 ms, the spike is discarded. However, if offset spikes greater than the step threshold persist for an interval more than the stepout threshold, by default 300 s, the system clock is stepped to the correct time.
All of these work-arounds for unneeded hacks (like in the article) drives my temper way up. Just do the simple thing in kernel space or the OS level. No suprises.