# vTaskGetRunTimeStats() and Usage tips

**URL:** <https://forums.freertos.org/t/vtaskgetruntimestats-and-usage-tips/11099>\
**Category:** Kernel\
**Created:** [November 11, 2020, 12:13am UTC](https://forums.freertos.org/t/vtaskgetruntimestats-and-usage-tips/11099 "2020-11-11T00:13:43Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![TFlynn](https://avatars.discourse-cdn.com/v4/letter/t/a8b319/32.png) [@TFlynn](https://forums.freertos.org/u/TFlynn)\
**Post date:** [November 11, 2020, 12:13am UTC](https://forums.freertos.org/t/vtaskgetruntimestats-and-usage-tips/11099/1 "2020-11-11T00:13:43Z")

</div>

I did look at the other posts.  
What is the recommended Timer to Tick ratio? I’m running 10x, 10KHz Timer & 1KHz Tick.  
I suspect I have aliasing.  
Some tasks react to hardware events, ie receiving a CAN message or a serial message.  
These are reading “\<1%”. I suspect they are using more than that. IDLE is about 80% & a Display Task thats at about 16%. The Display Task % is reasonable.  
Also, vTaskGetRunTimeStats() function call returns a string. The order of the tasks is jumping around. It appears to sort highest 5 to lowest. And output formating is a problem.  
Is there a way to get the (more) raw numbers instead of a formatted output?  
Thanks.

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [November 11, 2020, 3:09am UTC](https://forums.freertos.org/t/vtaskgetruntimestats-and-usage-tips/11099/2 "2020-11-11T03:09:03Z")

</div>

Have a look at [https://www.freertos.org/uxTaskGetSystemState.html](https://www.freertos.org/uxTaskGetSystemState.html) - it provides the raw data.

---

<div class="post-metadata">

**Author:** ![TFlynn](https://avatars.discourse-cdn.com/v4/letter/t/a8b319/32.png) [@TFlynn](https://forums.freertos.org/u/TFlynn)\
**Post date:** [November 12, 2020, 4:07pm UTC](https://forums.freertos.org/t/vtaskgetruntimestats-and-usage-tips/11099/3 "2020-11-12T16:07:36Z")

</div>

Thank you.  
What about Timer rate?  
Is it correct to assume that one or multiple Timer counts are required t get reasonably accurate usage times?  
Also, what happens when the counter overflows? are the returned values “junk” for a bit?

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [November 12, 2020, 5:21pm UTC](https://forums.freertos.org/t/vtaskgetruntimestats-and-usage-tips/11099/4 "2020-11-12T17:21:22Z")

</div>

There is no generic answer to how fast the clock should be. Naturally the faster the clock the more accurate the results will be, but also the sooner the clock will overflow. If you have tasks that run fleetingly and the timer clock is too slow then they may never register as having been executed. The data is only good until the clock overflows.

---

<div class="post-metadata">

**Author:** ![richard-damon](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/richard-damon/32/38_2.png) [@richard-damon](https://forums.freertos.org/u/richard-damon)\
**Post date:** [November 13, 2020, 7:57pm UTC](https://forums.freertos.org/t/vtaskgetruntimestats-and-usage-tips/11099/5 "2020-11-13T19:57:09Z")

</div>

One thing that at times would be useful would be the ability to change the type of the members that store accumulated time used to accumulate the run-time accumulation. It currently is fixed as a 32 bit type, which limits the running time/resolution for the states. For 32 bit processors, being able to use a 64 bit accumulator would still be reasonably efficient and allow much longer (virtually unlimited) run times even at high resolution. I would expect it to stay defaulted to 32 bits for backwards compatibility, and for use on 16 bit processors (where 64 bits would likely be to inefficient to use in the scheduler). Adding an optional #define for this type in FreeRTOSConfig.h shouldn’t be too hard.