Am 02.10.2026 um 06:30 schrieb Christian Schulte: > 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,
- wait for work - if waiting timed out - break vs. - wait for work - if waiting timed out - if timeout too short - continue - else - break
