On 2023-12-24 20:58, Jonathan Stone wrote:
On Sunday, December 24, 2023 at 02:43:55 AM PST, Johnny Billquist <bqt%softjar.se@localhost> wrote:> Oh? So we are actually not POSIX compliant on that one? Interesting. > (POSIX explicitly says that the timeout should be for an absolute time, > which means that if you for example update the clock, moving it > backwards, the timeout should still only happen when that time arrives, > and not after some precomputed number of ticks.) one could keep track, for every timeout, whether it's relative or absolute; and when the time is changed, walk the list of a-yet-unfired timeouts, updating all the "absolute" timeouts by the clock-change delta.
One could, indeed. And then it would be compliant. (I'd dislike it, but that's a very personal opinion. :-) )
Anyway .. I wonder if the "clock drift" is related to the clock drift I've heard about, on machines which don't have a hardware cycle-counter-style clock, and rely on clock-tick interrupts to track time. (for example, pmax 2100/3100; decstation 5000/200; (most) vax).I'd really like to help out with clock-drift', if I can do anything to help.
I am fairly sure all systems use the clock tick interrupt to track time in the end. No NetBSD port, as far as I know, is running a tickless implementation.
But I think the suggestion that the time adjustment might actually be a source of the problem is interesting, and should be investigated. It just takes so bloody long to do a full build these days. I still haven't finished, and can't start chasing this quite yet.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt%softjar.se@localhost || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol