'TIME' task cpuuse

Matthew J Fletcher amimjf at gmail.com
Tue Jan 14 13:37:04 UTC 2020


Of course without nanoseconds support in the BSP measuring the timer
callback duration is difficult as most calls will be less than a tick.

On Tue, 14 Jan 2020 at 08:41, Matthew J Fletcher <amimjf at gmail.com> wrote:

> Ok,
>
> So first step is to create a wrapper that all timers fire through, then an
> array to count the number of invocations per timer_id, after that some per
> timer_id time accounting.
>
> Will let you know if its anything outside my application.
>
>
> On Mon, 13 Jan 2020 at 15:01, Joel Sherrill <joel at rtems.org> wrote:
>
>>
>>
>> On Mon, Jan 13, 2020 at 8:53 AM Matthew J Fletcher <amimjf at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> My application seems to be using around 1/3rd of its total cpu usage in
>>> the 'TIME' task,. is this the task created by rtems_timer_initiate_server()
>>> ?
>>>
>>
>> Yes.
>>
>>>
>>> What would be the best way to get more information,. are there console
>>> commands that would emit more data, or do i need to instrument my
>>> application to see usage of all rtems_timer_xx callbacks ?
>>>
>>
>> rtems_timer_server_xx would be the ones going to the TIME Server.
>>
>> But 1/3 seems quite excessive. I would assume one of your timer server
>> routines is doing something unexpectedly heavy CPU-wise.
>>
>> I don't think there is any instrumentation in the server which would
>> help. Measuring the execution time of each invocation is what comes to
>> mind. My first thought is that this would be a nice debug option for
>> timers. But I am not sure how good this would be for ISR style.
>>
>> --joel
>>
>>>
>>> regards
>>> ---
>>> Matthew J Fletcher
>>>
>>> _______________________________________________
>>> users mailing list
>>> users at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/users
>>
>>
>
> --
>
> regards
> ---
> Matthew J Fletcher
>
>

-- 

regards
---
Matthew J Fletcher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20200114/d5dcba48/attachment.html>


More information about the users mailing list