Am 01.10.2026 um 02:42 schrieb Brian Brombacher: > > >> On Sep 30, 2026, at 5:07 PM, Christian Schulte <[email protected]> wrote: >> Am 30.09.2026 um 22:14 schrieb Stuart Henderson: >>>> On 2026-09-30, Christian Schulte <[email protected]> wrote: >>>> Am 30.09.2026 um 18:32 schrieb H. Hartzer: >>>>> I think this is largely a hardware support thing and you'll have a range >>>>> of supported speeds. Like you might have 800MHz, 1200MHz, 1800MHz, and >>>>> finally 2200MHz. >>>> It is. I failed to find a way to program the hardware clock generators >>>> in any way to accomplish this. It's like soldering a different quartz >>>> onto the PCB. I understand that. >>>> Maybe I need to explain what made me ask for this. Timeouts used by e.g. >>>> cnd_timedwait or pthreads_cond_timedwait and functions like those >>>> internally use CLOCK_REALTIME or CLOCK_MONOTONIC. The issue with this is >>>> that those clocks advance "in hardware". It can well happen that the >>>> scheduler never provided any compute to a thread waiting on some >>>> condition so that the condition may well time out, although the waiting >>>> thread never got scheduled in between - so to say. I am having a hard >>>> time setting up some environment I can use to reliable test this. >>> >>> not entirely reliable, but maybe run some stress processes (in ports; >>> e.g. in malloc mode might be good) or just a bunch of md5 -tttt to try >>> to starve it of cpu? >> >> It's not about starving the CPU. That would be easy. It's about >> functions taking e.g. a struct timespec to specify some absolute timeout >> value using a "hardware" definition of what is a second and what is a >> nanosecond completely independent of what the scheduler "thinks" is a >> second or a nanosecond. There is no way to specify relative timeouts, >> though. I am a bit lost here, I admit. > > You want to simulate a scenario where a process requests a timeout at cycle 0 > and then at cycle 10 it is woken up by that timeout, but never anywhere > between cycles 1-9 did it ever get a time slice… (“cycle” here has no actual > meaning, obviously it doesn’t represent anything like ticks, Hz, etc. just > using it as a counter of “time” passing).
The process is not woken up by some timeout. It just gets scheduled when the scheduler decides it to get scheduled. The timeout counters are hardware counters the scheduler does not know about. The scheduler does it's thing. The timeout counters do it's thing. Concurrently. An application can just query "timeout". But that "timeout" is ambiguous and cannot be used to distinguish between "time elapsed" and "compute elapsed". Regards, -- Christian
