Re: PSA: Clock drift and pkgin
On 2023-12-25 02:17, Robert Elz wrote: 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. Happy to see that this is finally getting fixed. Working on embedded systems where sometimes you have no clue what the absolute time is, current POSIX was just close to unusable, and we've had to do some pretty horrible workarounds. 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 Mon, 2023-12-25 00:26:34 +0100, Johnny Billquist wrote: > 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. The /60 finished installation; upon its first boot from local PiSCSI "disk", I found: [ 1.0672720] WARNING: lwp 30 (system rt_timer) flags 0x2000: timecounter went backwards from (1 + 0x36821f2990edf767/2^6d (cut off as I didn't have linewrap or logging active in `minicom`.) Didn't notice that with the slightly older image, but maybe it's only happening rarely. Waiting for it to fully come up (-> activated `ssh`, so it's generating host keys...) Will then give it a time and let it run idle over the day and loaded over night. (And maybe give that older image a few boots to see whether or not I can the a "timecounter went backwards" message from it...) MfG, JBG -- signature.asc Description: PGP signature
Re: PSA: Clock drift and pkgin
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. 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.
