'TIME' task cpuuse

[Joel Sherrill]

On Tue, Jan 14, 2020, 8:29 AM Matthew J Fletcher <amimjf at gmail.com> wrote:

> 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
>

It is possible that they could align. As tasks execute, they are going to
tend to run either as unblocked via time (e.g. tick) or another task
unblocking them. If they tend to run under a clock tick or two, this
activity could begin to cluster.  This is assuming a more event driven
system.

I tend to think this is less likely to happen with a more periodic system.

What's your clock tick quantum? I think a larger tick would have a higher
tendency to cluster. This is because more activities would tend to be
triggered and run to completion between two ticks

This is all spit balling and hypothetical. A white board, some hard
information, drawing event flow and timeline, and pondering would be needed
to see if this is happening.

--joel


> 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/446f560b/attachment.html>