'TIME' task cpuuse

[Matthew J Fletcher]

Free running counter is only 32khz, so ages in cpu time at 200mhz. There is
a nanosecond IEEE 1588 unit on the network interface ....

I've identified at least 6 timers going at 10ms, only 1-in-1000 invocations
seem take more than a tick to run,.. they are all started in the same
second but with randomish-jitter between the rtems_time_server_fire_after()
calls,.. rtems would not be aligning them to all run at the same time (on
tick boundary) would it ?

On Tue, 14 Jan 2020 at 14:02, Joel Sherrill <joel at rtems.org> wrote:

>
>
> On Tue, Jan 14, 2020 at 7:37 AM Matthew J Fletcher <amimjf at gmail.com>
> wrote:
>
>> Of course without nanoseconds support in the BSP measuring the timer
>> callback duration is difficult as most calls will be less than a tick.
>>
>
> Yeah, you can't use the clock services from rtems in that case since they
> don't have a high enough resolution.
>
> Do you have a free running counter/timer you can read?
>
> I assume you only have a finite number of timer service routines called
> from
> the Timer Server thread. Can you benchmark them outside the application?
> If this is a straightforward case of a single invocation of a method
> running too
> long, that would be sufficient to figure it out. Or do you have something
> that is
> processing a set of things and sometimes the set is large?
>
> Hmmm... it is possible that if the clock tick configured is larger than
> any of
> your timer intervals, they are firing in clusters. Say you have a 10
> millisecond
> clock tick configured and all your timers fire in less than that. They
> will all
> fire in 1 tick. Any chance of a degenerate set like this?
>
> --joel
>
>
>> 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
>>
>>

-- 

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