Hi,
We are trying to profile our code and going through the API to see whats the best way to do that.
The way 'stats' is defined, it looks like its measuring instruction cycles while 'time' counts system ticks. Is resolution the only difference between them. Is there a recommended way on how each should be used?
Thanks,
AQ
Understand difference between stats and time in thread_t
- sabdulqadir
- Posts: 49
- Joined: Fri Mar 23, 2018 7:29 pm
- Has thanked: 13 times
- Been thanked: 4 times
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Understand difference between stats and time in thread_t
Hi,
Statistics is generally recommended but it is not available on the M0 because that core does not have the necessary support for a real time counter.
CH_CFG_USE_TM enables the time measurement facility based on the real time counter. Clock accurate.
CH_DBG_STATISTICS enables runtime statistics based on the real time counter. Clock accurate.
CH_DBG_THREADS_PROFILING enables a legacy profiler based on system tick, it is not compatible with tick-less mode of course. It counts how many time the system tick interrupt hits each thread so it requires long run times for statistical accuracy.
It depends on what you need to do, please explain your need (customers can use also private support).
Giovanni
Statistics is generally recommended but it is not available on the M0 because that core does not have the necessary support for a real time counter.
CH_CFG_USE_TM enables the time measurement facility based on the real time counter. Clock accurate.
CH_DBG_STATISTICS enables runtime statistics based on the real time counter. Clock accurate.
CH_DBG_THREADS_PROFILING enables a legacy profiler based on system tick, it is not compatible with tick-less mode of course. It counts how many time the system tick interrupt hits each thread so it requires long run times for statistical accuracy.
It depends on what you need to do, please explain your need (customers can use also private support).
Giovanni
- sabdulqadir
- Posts: 49
- Joined: Fri Mar 23, 2018 7:29 pm
- Has thanked: 13 times
- Been thanked: 4 times
Re: Understand difference between stats and time in thread_t
Thanks Giovanni for a quick reply. Appreciate that.
For the moment, our requirement is simple. Measure CPU load. I guess the profiler is the best way to do it. Although had to define CH_CFG_ST_TIMEDELTA to enable it. Lets us know if there are any other ways to do it as well.
Also when you say "real time counter", what are the units of count?
Also one more question. Do defining CH_CFG_ST_TIMEDELTA = 0 make the system tickfull(pardon my humor)?
If yes, I feel this sentence does not make it very evident (also because of the sentence immediately following it).
"If this value is zero then the system uses the classic periodic tick."
Thanks,
AQ
For the moment, our requirement is simple. Measure CPU load. I guess the profiler is the best way to do it. Although had to define CH_CFG_ST_TIMEDELTA to enable it. Lets us know if there are any other ways to do it as well.
Also when you say "real time counter", what are the units of count?
Also one more question. Do defining CH_CFG_ST_TIMEDELTA = 0 make the system tickfull(pardon my humor)?
If yes, I feel this sentence does not make it very evident (also because of the sentence immediately following it).
"If this value is zero then the system uses the classic periodic tick."
Thanks,
AQ
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Understand difference between stats and time in thread_t
Hi,
Setting CH_CFG_ST_TIMEDELTA to zero disables the tick-less mode of the kernel, it reverts to a classic tick system.
About CPU load, probably the profiling is the simplest way if you don't need tick-less. It can also been calculated using statistics because the number of cycles spent by each thread are calculated. Statistics have overhead because the added code to critical code paths.
I would try doing something a bit different:
- Define a global variable set it to zero.
- Increase this variable in your idle loop (there is an hook for this), use a critical zone around the increase.
- Read it then divide it by a constant using a periodic virtual timer (every second or so, sloooow ticks).
That variable would represent your load, lower values are higher loads. Low overhead, compatible with tick-less, no need of realtime counter.
The real time counter is an internal register in Cortex-M which is increased continuously every CPU clock cycle. It is 32 bits large and it wraps down to zero.
Giovanni
Setting CH_CFG_ST_TIMEDELTA to zero disables the tick-less mode of the kernel, it reverts to a classic tick system.
About CPU load, probably the profiling is the simplest way if you don't need tick-less. It can also been calculated using statistics because the number of cycles spent by each thread are calculated. Statistics have overhead because the added code to critical code paths.
I would try doing something a bit different:
- Define a global variable set it to zero.
- Increase this variable in your idle loop (there is an hook for this), use a critical zone around the increase.
- Read it then divide it by a constant using a periodic virtual timer (every second or so, sloooow ticks).
That variable would represent your load, lower values are higher loads. Low overhead, compatible with tick-less, no need of realtime counter.
The real time counter is an internal register in Cortex-M which is increased continuously every CPU clock cycle. It is 32 bits large and it wraps down to zero.
Giovanni
- sabdulqadir
- Posts: 49
- Joined: Fri Mar 23, 2018 7:29 pm
- Has thanked: 13 times
- Been thanked: 4 times
Re: Understand difference between stats and time in thread_t
Ok,
Got answer for most of my queries. Thanks
So a bit confused on your implementation for profiling.
For cortex-M, port_wait_for_interrupt() would wait on WFI until an interrupt is triggered.
If the VT is set to 1sec, the global variable would just tell us how many times did we enter idle thread in that given second.
We wont have a track of duration it stayed in that loop.
Or am I missing anything?
Thanks,
AQ
Got answer for most of my queries. Thanks
So a bit confused on your implementation for profiling.
For cortex-M, port_wait_for_interrupt() would wait on WFI until an interrupt is triggered.
If the VT is set to 1sec, the global variable would just tell us how many times did we enter idle thread in that given second.
We wont have a track of duration it stayed in that loop.
Or am I missing anything?
Thanks,
AQ
- sabdulqadir
- Posts: 49
- Joined: Fri Mar 23, 2018 7:29 pm
- Has thanked: 13 times
- Been thanked: 4 times
Re: Understand difference between stats and time in thread_t
If we had PRE and POST hooks in idle, we would be able to measure the time in the idle thread.
We could use VT to make sure they do not overflow.
Would that be another way of profiling load?
Thanks,
AQ
We could use VT to make sure they do not overflow.
Would that be another way of profiling load?
Thanks,
AQ
Re: Understand difference between stats and time in thread_t
Is it true that (assuming no overflow happens), the total time logged by stats for all threads should track the current system time?
Also, that the cumulative time for each thread is the actual execution time of the thread + any interrupts that occurred in the thread. The stats timer for the thread is stopped when the context switch occurs, which would be at the end of an interrupt (or a chain of nested interrupts) ..
Also, that the cumulative time for each thread is the actual execution time of the thread + any interrupts that occurred in the thread. The stats timer for the thread is stopped when the context switch occurs, which would be at the end of an interrupt (or a chain of nested interrupts) ..
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Understand difference between stats and time in thread_t
sabdulqadir wrote:For cortex-M, port_wait_for_interrupt() would wait on WFI until an interrupt is triggered.
True but WFI is optional, you could not use it. It depends on your requirements.
Giovanni
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Understand difference between stats and time in thread_t
sabdulqadir wrote:If we had PRE and POST hooks in idle, we would be able to measure the time in the idle thread.
Statistics module does this for all threads, it measures from context switch to context switch.
Giovanni
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Understand difference between stats and time in thread_t
faisal wrote:Is it true that (assuming no overflow happens), the total time logged by stats for all threads should track the current system time?
Also, that the cumulative time for each thread is the actual execution time of the thread + any interrupts that occurred in the thread. The stats timer for the thread is stopped when the context switch occurs, which would be at the end of an interrupt (or a chain of nested interrupts) ..
Cumulative time should be equal to system time (adjusing for the different clocks), I have not verified this but it counts end to end including also the measurement code.
Giovanni
Who is online
Users browsing this forum: No registered users and 22 guests