Compute the time elapsed when switching between two threads

Hello fellow developers !

I have a simple question: How one could compute the time elapsed when switching from thread A to thread B?

Any advice or lead is welcome!

Regards, Julien

Hi Julien,

I think this test should be doing what you want, I did not look at it just knew it existed.

https://github.com/RIOT-OS/RIOT/tree/master/test/bench_thread_yield_pingpong

Regards, Ga�tan - cladmi

Hi Gaëtan,

Thank you for your answer!

I did look at this test and it counts the number of context switches between two threads of the same priority in one second.

What I want is something more abstract (any thread, any priority). To reformulate my question, let’s assume I have two threads. It doesn’t matter what they are doing. One of the threads will be interrupted by the other and a context switch will occur. What I want to know is how much time is spent in the context switching.

I don’t think this is possible at the application-level.

Regards, Julien

Would you be able to get the measurements you are looking for using this approach instead? The low priority thread is toggling a gpio pin in a tight loop. The other thread toggles a different pin as soon as it is resumed. You would need external equipment to get the time between the two, but it should give a fairly accurate measurement for a single context switch. /Joakim

Hi Joakim,

Indeed, using external equipment like an oscillograph was the first thing I did.

But I am looking to compute the context switching time only with software.

I am pretty sure I will have to tweak the kernel to get such measurements :disappointed: And even doing so, I will not have the closest value to the real elapsed time.

Regards, Julien

Hi Julien,

Indeed, using external equipment like an oscillograph was the first thing I did.

But I am looking to compute the context switching time only with software.

I am pretty sure I will have to tweak the kernel to get such measurements :disappointed: And even doing so, I will not have the closest value to the real elapsed time.

How exact do you expect the value to be?

As you've already realized, the benchmarks in tests/bench_* measure the number of context switches within one second, for threads of the same priority. (Actually, it counts double context switches.)

For the IPC tests, the priority of the threads doesn't matter, you should be able to change them. But that should also not really change the results.

You can easily calculate the time taken by one context switch.

On real MCUs, these numbers are fairly constant, and the overhead of the actual test is minimal, so the results should be within a very low single digit percentage of the actual time.

A less portable improvement would be to set up a periph timer with maximum (e.g, MCU) frequency. Then take the current timer value, trigger a context switch (e.g., through "time_sleep()"), and in the other thread, again as first thing take the timer value. That way you'd get almost cycle-perfect context switch time measurements.

Kaspar