> 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.
