Execution time

Execution time

[Leandro Bucci]

Hi, I noticed a very strange but also interesting fact. When a certain
periodic task is executed, if the period is small (for example 0.5ms) I
have that the execution times are more or less constant (about 5 micro
seconds). If, on the other hand, the period of the same task is larger (for
example 10ms), the execution times are less predictable and range from 5
micro seconds to 15 micro seconds.

How is this possible? I am using a raspberry Pi3 and the task is running on
a core dedicated to xenomai.

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Mail
priva di virus. www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: Execution time

[Jan Kiszka]

On 03.03.21 15:45, Leandro Bucci via Xenomai wrote:
> Hi, I noticed a very strange but also interesting fact. When a certain
> periodic task is executed, if the period is small (for example 0.5ms) I
> have that the execution times are more or less constant (about 5 micro
> seconds). If, on the other hand, the period of the same task is larger (for
> example 10ms), the execution times are less predictable and range from 5
> micro seconds to 15 micro seconds.
> 
> How is this possible? I am using a raspberry Pi3 and the task is running on
> a core dedicated to xenomai.

In general, you can see cache "temperature" effects when reducing the
period of a task: The more frequently it runs, the hotter the cache will
be and the less likely it is that relevant content for that task has be
evicted. But all that depends on many factors, the non-rt load, the load
of the task itself, the caching system etc.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: Execution time

[Leandro Bucci]

very interesting thanks

Il lun 8 mar 2021, 11:23 Jan Kiszka <jan.kiszka@siemens.com> ha scritto:

> On 03.03.21 15:45, Leandro Bucci via Xenomai wrote:
> > Hi, I noticed a very strange but also interesting fact. When a certain
> > periodic task is executed, if the period is small (for example 0.5ms) I
> > have that the execution times are more or less constant (about 5 micro
> > seconds). If, on the other hand, the period of the same task is larger
> (for
> > example 10ms), the execution times are less predictable and range from 5
> > micro seconds to 15 micro seconds.
> >
> > How is this possible? I am using a raspberry Pi3 and the task is running
> on
> > a core dedicated to xenomai.
>
> In general, you can see cache "temperature" effects when reducing the
> period of a task: The more frequently it runs, the hotter the cache will
> be and the less likely it is that relevant content for that task has be
> evicted. But all that depends on many factors, the non-rt load, the load
> of the task itself, the caching system etc.
>
> Jan
>
> --
> Siemens AG, T RDA IOT
> Corporate Competence Center Embedded Linux
>

Execution time

[Leandro Bucci]

hi, I'm doing some tests. I'm measuring the execution time of a task. the
task takes about 10us to complete. But I am noticing that it takes even
just over 5us at times. I therefore don't have a constant running time.
It's normal? maybe because the precision is of the order of micro seconds?

Re: Execution time

[Per Oberg]

----- Den 16 feb 2021, på kl 12:34, xenomai xenomai@xenomai.org skrev:

> hi, I'm doing some tests. I'm measuring the execution time of a task. the
> task takes about 10us to complete. But I am noticing that it takes even
> just over 5us at times. I therefore don't have a constant running time.
> It's normal? maybe because the precision is of the order of micro seconds?

It depends on 
 * The task, and it's priority
 * How you are measuring time
 * What hardware you are using
 * What else is happening in the system

If it's a fairly simple task it shouldn't vary to much, but if the task may or may not trigger some extra action. Modern complex CPU's have a lot of features that speeds things up for repetitive code. For example, the time of reading a memory buffer may depend on what was read before. 

If there are other high-priority tasks going on, or perhaps a hardware interrupt coming in your tasks execution may be delayed. 

Time measurement may differ depending on what functions you use. Some call the Linux clock, some use Xenomai based clocks.

Depending on the hardware you may or may not be able to control exactly what is happening in your system. This is strictly from memory, but SMI interrupts on the PC platform is one such thing that is out of your hands. Raspberry Pi is another can of worms if I recall correctly. Firstly, ARM has regular interrupts and fast interrupts and I am not sure where Xenomai makes the cut. Then there is the broadcom chip of the RPi that I think has some handling of the USB that you don't have control over. 

Per Öberg 

Re: Execution time

[Leandro Bucci]

Thanks for the explanation.  Yes, I am using a Raspberry Pi 3, so in a
sense it is normal to have these "small" time differences.  I am running
only one periodic task (1ms period) and execution time between 5 and 10
micro seconds.

Il mar 16 feb 2021, 15:03 Per Oberg <pero@wolfram.com> ha scritto:

>
> ----- Den 16 feb 2021, på kl 12:34, xenomai xenomai@xenomai.org skrev:
>
> > hi, I'm doing some tests. I'm measuring the execution time of a task. the
> > task takes about 10us to complete. But I am noticing that it takes even
> > just over 5us at times. I therefore don't have a constant running time.
> > It's normal? maybe because the precision is of the order of micro
> seconds?
>
> It depends on
>  * The task, and it's priority
>  * How you are measuring time
>  * What hardware you are using
>  * What else is happening in the system
>
> If it's a fairly simple task it shouldn't vary to much, but if the task
> may or may not trigger some extra action. Modern complex CPU's have a lot
> of features that speeds things up for repetitive code. For example, the
> time of reading a memory buffer may depend on what was read before.
>
> If there are other high-priority tasks going on, or perhaps a hardware
> interrupt coming in your tasks execution may be delayed.
>
> Time measurement may differ depending on what functions you use. Some call
> the Linux clock, some use Xenomai based clocks.
>
> Depending on the hardware you may or may not be able to control exactly
> what is happening in your system. This is strictly from memory, but SMI
> interrupts on the PC platform is one such thing that is out of your hands.
> Raspberry Pi is another can of worms if I recall correctly. Firstly, ARM
> has regular interrupts and fast interrupts and I am not sure where Xenomai
> makes the cut. Then there is the broadcom chip of the RPi that I think has
> some handling of the USB that you don't have control over.
>
> Per Öberg
>