Hacker News Reader

Comment by STRML | Hacker News Reader

> It is unclear what he means by "If your system clock jumps from one time to another...". If this is talking about NTP, it's probably accurate.

I don't know what he's talking about either. Most popular NTP clients (ntpd, chrony) will try very hard to make sure this never happens by simply slowing down or speeding up time. You don't know what will break if you just gap time like that.

View on HN

There isn't really a mechanism to slow down or speed up time on Linux (this has become clear with the recent time namespace discussions), you'd have constantly re-set the time to whatever slowed-down clock you are trying to emulate -- which isn't hard but it would result in lost of micro-jumps backwards or forwards which would be more chaotic than just one macro-jump.

ntpd and chrony might do it (I'm not sure), but systemd's NTP implementation (which is widely used, even though it does have many other issues -- such as not implementing the spec properly IIRC) does just jump time when you enable NTP on a system where it was disabled. From memory, back when I used ntpd, it did the same thing but I could be mistaken.

>"There isn't really a mechanism to slow down or speed up time on Linux (this has become clear with the recent time namespace discussions)"

Interesting, might you have any links to these discussions?

There is an LWN article about it[1], and the discussions are all on LKML[2].

[1]: https://lwn.net/Articles/766089/ [2]: https://lore.kernel.org/lkml/20180919205037.9574-1-dima@aris...

Yes there is, and has been for a very long time, specifically to support ntpd.

http://man7.org/linux/man-pages/man2/adjtimex.2.html

Sorry, I guess you're right. I misunderstood the discussion in [1], the reason why clock frequency change wasn't included in the timens patchset is because it was decided to be far too complicated (not because current kernel timekeeping cannot do it). Not to mention that most people would want to adjust the clock speed for indefinite periods of time, which isn't what adjtimex is meant for.

[1]: https://lore.kernel.org/lkml/20180919205037.9574-1-dima@aris...

ntpd doesn't attempt that if the gap between recorded and actual time is far off (e.g. if the CMOS battery dies, which is the most common case I've encountered). In those cases, you're expected to manually intervene (e.g. by running ntpdate), which does indeed gap time.

Not sure about chrony, since I haven't used it (or heard of it, admittedly).

Most systems will jump the clock once at startup. This is sometimes implemented as a jump during the ntp startup script, which may also be run by the admin at any time.

The whole article is about edge cases. It doesn’t really matter if they aren’t super common: the result is that mtimes do act weird sometimes, and if you build a system that depends on them, it will also act weird sometimes.

Reply on news.ycombinator.com