Re: PSA: Clock drift and pkgin
Date:Sun, 24 Dec 2023 13:49:53 +0100 From:Johnny Billquist Message-ID: | In my opinion, all of these POSIX calls that take a time argument should | really have been done the same as clock_gettime(), in that you specify | what clock it should be based on. The next version of POSIX will contain pthread_cond_clockwait() which is just like pthread_cond_timedwait() but has a clock_id parameter. | As it is now, it is (or should be according to POSIX) unconditionally | CLOCK_REALTIME. Not sure about the current released standard, and too lazy to look ... but in the coming one that's not true either: The pthread_cond_timedwait() function shall be equivalent to pthread_cond_clockwait(), except that it lacks the clock_id argument. The clock to measure abstime against shall instead come from the condition variable's clock attribute which can be set by pthread_condattr_setclock() prior to the condition variable's creation. If no clock attribute has been set, the default shall be CLOCK_REALTIME. kre
Re: PSA: Clock drift and pkgin
On 2023-12-24 20:58, Jonathan Stone wrote: On Sunday, December 24, 2023 at 02:43:55 AM PST, Johnny Billquist 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: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: PSA: Clock drift and pkgin
On 2023-12-24 11:43, Johnny Billquist wrote: On 2023-12-24 09:26, Michael van Elst wrote: sim...@netbsd.org (Simon Burge) writes: qemu uses ppoll() which is implemented with pollts() to do emulated timers, so that doesn't help here. I don't know what simh uses,nor any of the other emulators. simh uses pthread_cond_timedwait(). This actually waits using TIMER_ABSTIME for a deadline, but which is converted to a timeout with ts2timo() and passed to sleepq_block() as a number of ticks to wait for. 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.) By the way - I should point out that I am not advocating that we change this to be POSIX compliant. I do think POSIX is broken here. In my opinion, all of these POSIX calls that take a time argument should really have been done the same as clock_gettime(), in that you specify what clock it should be based on. As it is now, it is (or should be according to POSIX) unconditionally CLOCK_REALTIME. But depending on what you are doing, CLOCK_MONOTONIC might be what you really wished you could use. I think Linux have some private extension to the whole thing, which makes it possible to pick other clocks, but I've forgotten the details. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: PSA: Clock drift and pkgin
On 2023-12-24 09:26, Michael van Elst wrote: sim...@netbsd.org (Simon Burge) writes: qemu uses ppoll() which is implemented with pollts() to do emulated timers, so that doesn't help here. I don't know what simh uses, nor any of the other emulators. simh uses pthread_cond_timedwait(). This actually waits using TIMER_ABSTIME for a deadline, but which is converted to a timeout with ts2timo() and passed to sleepq_block() as a number of ticks to wait for. 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.) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: PSA: Clock drift and pkgin
sim...@netbsd.org (Simon Burge) writes: >qemu uses ppoll() which is implemented with pollts() to do emulated >timers, so that doesn't help here. I don't know what simh uses, nor >any of the other emulators. simh uses pthread_cond_timedwait(). This actually waits using TIMER_ABSTIME for a deadline, but which is converted to a timeout with ts2timo() and passed to sleepq_block() as a number of ticks to wait for. ts2timo() uses tvothz() which rounds up...
