Am 01.10.2026 um 04:43 schrieb Brian Brombacher: > > >> On Sep 30, 2026, at 9:35 PM, Christian Schulte <[email protected]> wrote: >> >> 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". > > You are arguing over words here. Sorry I did not describe exactly how it > works correctly, but my point is exactly how you described it earlier. Then > you ignored the rest of my email. > > Use “qemu -icount shift=11,sleep=off -rtc clock=vm” to simulate a 500 kHz > processor. QEMU was already suggested to you and you ignored it.
I did not ignore it, of course. That was very helpful. There just is no way to find out about such a situation in code. That would be needed to automatically calculate the minimum supported timeout value automatically. Timeouts can be hard coded or configured by the user in some way. That's fine. Regarding that arguing over words. The issue I was trying to solve is that "timeout" means time elapsed. There is nothing wrong about that. A thread/process receicing a "timeout" can just detect that a given amount of time has elapsed. It cannot detect if it has ever been run between such timeouts. That would be needed to automatically adjust the timeout to avoid them to be too short. Impossible, I think. So be it. Regards, -- Christian
