Timer with ThreadSleepNoEarlyWake

[PhilDay-CT]

As part of a demo I have various threads that I want to sleep for a couple of seconds. The code is basically something like the following and is running the latest version of the dev container.

void __cheri_compartment("timer") init()
{
	int loop = 1;
	while (true)
	{
		Timeout t1{1000};
		thread_sleep(&t1);
		Debug::log("thread {} Woke {}", thread_id_get(), loop++);
	}
}

which was giving me a sleep of about 1 second.

Having recently rebased my repo the timers are now returning more or less immediately. Turning on debugging in the scheduler I can see that they are waking early:

Scheduler: Created thread for trusted stack 0x80000230 (v:1 0x80000230-0x80000338 l:0x108 o:0xa p: G RWcgml -- ---)
Scheduler: Thread 0x1 sleeping for 0x3e8 ticks
Scheduler: Woke thread 0x1 0x30d3f cycles early
Timer : thread 0x1 Woke 1
Scheduler: Thread 0x1 sleeping for 0x3e8 ticks
Scheduler: Woke thread 0x1 0x30d3e cycles early
Timer : thread 0x1 Woke 2

So digging in the code I saw there's now a flags argument to control this, but even with that set

void __cheri_compartment("timer") init()
{
	int loop = 1;
	while (true)
	{
		Timeout t1{1000};
		thread_sleep(&t1, ThreadSleepNoEarlyWake);
		Debug::log("thread {} Woke {}", thread_id_get(), loop++);
	}
}

although the log no longer shows that the thread is waking early

Scheduler: Created thread for trusted stack 0x80000230 (v:1 0x80000230-0x80000338 l:0x108 o:0xa p: G RWcgml -- ---)
Scheduler: Thread 0x1 sleeping for 0x3e8 ticks
Timer : thread 0x1 Woke 1
Scheduler: Thread 0x1 sleeping for 0x3e8 ticks
Timer : thread 0x1 Woke 2

it still returns more or less immediately - I was expecting that telling it not to wake early would get me back to the previous behaviour.

Clearly I'm missing something , can someone point me in the right direction please ?

BTW I did try using
Timeout t1{MS_TO_TICKS(1000)};
But that seems to result in an even smaller value being passed into the sleep.

[davidchisnall]

This looks like a bug. I would expect your code to sleep for at least 1000 ticks (which, on Sonata, is 10s, so MS_TO_TICKS(1000) would give 100 ticks). Is this Sonata or some other target?

[davidchisnall]

We calculate the time for expiring timers here and then expire them in the function above. I wonder if we're seeing 32-bit integer overflow there and ending up with a very small time distance? I don't think that should happen, but that area is probably near the bug. I can try to reproduce this tomorrow morning and see.

[PhilDay-CT]

I'm running the dev container, so the target is Sail.

I'll take a look at that code and see if I can spot anything.

[davidchisnall]

Oh, okay. In simulation, we elapse time very fast because time is not real.

[davidchisnall]

I hadn't considered demos in sail (there's also the Ibex sim there, but I think it has the same issue - we have some #ifdef SIMULATION things that just assume time is an illusion, lunchtime doubly so).

[davidchisnall]

FWIW, doing this on Sonata does sleep for one second between each tick.

I'm a bit surprised it looked like it worked on Sail previously. The Sail config pretends that the machine runs at 2000 instructions per second, with 10 ticks per second (so 200 instructions per tick). A 1000 tick sleep is therefore 200,000 instructions, which is probably around half a second on my machine, so vaguely close but only by coincidence.

[PhilDay-CT]

It looks like timer.h has evolved quite a lot from the version I was previously working against. Looking at the code it looks like the reason this is jumping directly to the next timer is because threadHasNoPeers is evaluating to true,

https://github.com/microsoft/cheriot-rtos/blob/7f4c6101c7d7467ef12de37fa2d5ac2cb91cbfce/sdk/core/scheduler/timer.h#L80C3-L103C4

which means that nextTick gets set to DistantFuture and the clock seems to then jump directly to the value for the timer rather that going though the ticks inbetween ?

If I force threadHasNoPeers to false then I get the timers working in realtime (rather than lunchtime).

[PhilDay-CT]

So no way on sail to achieve an idle wait now then with the tickless scheduler ?

[davidchisnall]

There never was, you just had an accidental busy-wait loop that looked a bit like you had one (that would go away if the Sail JSON had more sensible values for the tick length - 2000 instructions is very silly). You can do a busy wait, or you can use the Ibex simulator if you want something that looks a bit more like a real system. Sail has no input sources or notion of time, Ibex sim has both (the UART works for reading and writing) and so is a better choice for demos.

[rmn30]

So no way on sail to achieve an idle wait now then with the tickless scheduler ?

I don't think so, sorry. Could you use a busy wait instead? Seems like it only worked previously because the ticky scheduler was so inefficient!

If you really want we could potentially add an option to disable the Sail wfi optimisation, but probably better to run on Ibex.

[PhilDay-CT]

@rmn30 - Running on ibex if fine in this case ;-)

[rmn30]

that would go away if the Sail JSON had more sensible values for the tick length - 2000 instructions is very silly

As a side note this is not quite correct. Sail time also has another quirk, which is that mcycle and mtime actually increment every 100 instructions (Sail has IPC of 100!). I think this means the current timer_hz of 2000 and tickrate_hz of 10 in sail.json gives about 20000 instructions per timer tick. This is probably still a bit low.

[PhilDay-CT]

Yep - ibex sim works fine ;-)

Thanks for all the patience and explanations