Ancestors

Written by Laurence Tratt on 2025-01-16 at 19:40

CLOCK_MONOTONIC on Linux is the gift that keeps giving (to me, at least). In the past it wasn't monotonic -- that's been fixed so the name is at least no longer wrong.

But it turns out that it doesn't advance over suspend/resume, so it is monotonic, but not in a useful manner. For that, one has to use use CLOCK_BOOTTIME...

=> More informations about this toot | More toots from ltratt@mastodon.social

Toot

Written by David Chisnall (Now with 50% more sarcasm!) on 2025-01-16 at 20:43

@ltratt I am surprised monotonic would do anything apart from that (does it elsewhere?). It counts the time that the kernel has observed. How do you tell how much time has elapsed while suspended? You need to rely on some external source such as an RTC or NTP server, presumably. What happens if that runs backwards?

=> More informations about this toot | More toots from david_chisnall@infosec.exchange

Descendants

Written by Laurence Tratt on 2025-01-17 at 08:51

@david_chisnall Preventing observed time going backwards is, I'm pretty sure, something that if can handle ;) Personally I don't expect "monotonic" time to exactly match the real world (time is hard) but I would hope that it at least roughly correlates. You're right, though, that I was wrong to say this is a Linux thing: it seems OpenBSD's CLOCK_MONOTONIC also works in the same way. Maybe I'm odd in thinking that "time except when suspended" is rarely a useful thing to know...

=> More informations about this toot | More toots from ltratt@mastodon.social

Written by David Chisnall (Now with 50% more sarcasm!) on 2025-01-17 at 11:23

@ltratt It's mostly what I want. I'm not sure what the use case is otherwise. For example, if I have a timeout for a blocking operation (e.g. a mutex), I don't really want the monotonic clock to jump forwards a day because of a suspend or VM migration and trigger the timeout.

A thing that is 'wall clock time elapsed, except when it isn't because our wall clock time is non-monotonic, but don't rely on it' doesn't seem useful.

The two cases I normally want from clocks are:

=> More informations about this toot | More toots from david_chisnall@infosec.exchange

Written by Laurence Tratt on 2025-01-17 at 14:12

@david_chisnall Interesting -- I have no use for the existing behaviour! I often have "wake up in X seconds and do Y" where "X seconds" is "wall-clock elapsed". A challenge here is that it's surprisingly challenging is to get a notion of "real-world time": there are lots of ways of using it and getting it wrong.

=> More informations about this toot | More toots from ltratt@mastodon.social

Written by David Chisnall (Now with 50% more sarcasm!) on 2025-01-17 at 14:27

@ltratt Any time I want that, it's because I want to run a thing with reference to some calendar. For example, do this at 4pm, or do this every third Sunday in a month. And that's really hard to do right. Monotonic clock for timeouts works well though. I'm going to wait for this service to respond for two seconds and, if it doesn't, I might spawn a new process to create it, for example, would be broken horribly if every suspend/resume triggered the timeout in every waiter.

What is your use case for wanting X seconds of wall-clock (but not real wall clock) time?

=> More informations about this toot | More toots from david_chisnall@infosec.exchange

Written by Laurence Tratt on 2025-01-17 at 14:33

@david_chisnall Yes, in essence I want to put a thread to sleep until a given time in the real world. I am willing to accept some slop, so NTP-ish changes don't worry me, but suspend/resume is a problem. I could wake up a lot, but that's unsatisfactory for obvious reasons. CLOCK_BOOTTIME is pretty much exactly what I want.

=> More informations about this toot | More toots from ltratt@mastodon.social

Written by David Chisnall (Now with 50% more sarcasm!) on 2025-01-17 at 14:45

@ltratt Yup, monotonic is not for you then. That's what wall clock is for, but sleeping until a wall-clock time has elapsed has problems if the clock moves backwards (I had one computer boot with a BIOS bug that caused it to think it was in 2038 until after the first NTP sync, for example).

To do it right, you ideally need to listen to whatever notification fires when someone calls adjtime or equivalent interfaces, but failing that can wake up periodically on the monotonic clock and see what the current time is.

=> More informations about this toot | More toots from david_chisnall@infosec.exchange

Written by Laurence Tratt on 2025-01-17 at 14:53

@david_chisnall I agree that there isn't a great way of doing this, at least not one that involves huge amounts of platform-specific fiddling. It's surprising, because it seems a fairly obvious thing to want to do but there again it may just reflect the paucity of daemons. I wish there were more of them, as they're such useful bits of software!

=> More informations about this toot | More toots from ltratt@mastodon.social

Written by David Chisnall (Now with 50% more sarcasm!) on 2025-01-17 at 15:14

@ltratt I expected there to be at least a devd event on adjkern on #FreeBSD, but there doesn't seem to be one (looking at the code). Ideally, I'd want a kqueue event type so that I can add it to anything waiting on wall-clock timeouts and recompute them if it's called.

=> More informations about this toot | More toots from david_chisnall@infosec.exchange

Written by Laurence Tratt on 2025-01-17 at 17:19

@david_chisnall I'm also not sure how one would do this on OpenBSD.

=> More informations about this toot | More toots from ltratt@mastodon.social