WARNSW, NULL); calls to the
> real time threads to catch mode switches. I have not found any mode
> switches yet. I will enable the debug options to find the latency. But the
> bigger problem is the higher execution time. It is taking longer to execute
> the same routine on Xenomai user
Hi Greg,
I added the pthread_setmode_np(0, PTHREAD_WARNSW, NULL); calls to the
real time threads to catch mode switches. I have not found any mode
switches yet. I will enable the debug options to find the latency. But the
bigger problem is the higher execution time. It is taking longer to
On Mon, Sep 13, 2021 at 1:49 PM Rajesh Venkataraman via Xenomai <
xenomai@xenomai.org> wrote:
> -- Forwarded message -
> From: Rajesh Venkataraman
> Date: Mon, Sep 13, 2021 at 10:41 AM
> Subject: Re: Execution time on Xenomai user thread is high
> To: Gre
-- Forwarded message -
From: Rajesh Venkataraman
Date: Mon, Sep 13, 2021 at 10:41 AM
Subject: Re: Execution time on Xenomai user thread is high
To: Greg Gallagher
Hi Greg,
Below are the results of the autotune and latency tests. I do not have any
debug features enabled.
Rajesh
l time routine in Xenomai user thread. Our platform is i.MX6 (ARM
> Cortex-A9 Quad Core) running at 996 MHz. Is that latency reasonable for
> Xemonai? We are also seeing something strange. The execution time of the
> real time routines is twice as long as it took on the RTOS. We are not
>
? We are also seeing something strange. The execution time of the
real time routines is twice as long as it took on the RTOS. We are not
making any calls to the Linux inside these real time routines. The
execution time of the routine is 500 microseconds in Xenomai thread. But on
an RTOS running this
very interesting thanks
Il lun 8 mar 2021, 11:23 Jan Kiszka 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 e
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 othe
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 1
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 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
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?
t_task_slice().
An option to actually cap the execution time of a thread at a certain
priority level would be to use the sporadic server scheduling
(SCHED_SPORADIC). When the time limit is reached, the thread priority is
lowered, until some conditions are met to switch it back to normal
pri
Hello,
Related to my troubleshooting thread of the last couple days, but this is a
separate and simple question.
In POSIX skin is there a way of assigning a high-priority RT thread/task a
timeslice such that it must yield execution if it exceeds its allotted
time? Or is this only possible in the
activation should be minimal or at least known with a reasonable small
jitter (magnitudes smaller than 1 ms).
But before buying the card I'd like to have some information about the
timing-performance of this setup:
1) What execution time (or magnitude of execution time) for DIO,
es
uying the card I'd like to have some information about the
timing-performance of this setup:
1) What execution time (or magnitude of execution time) for DIO,
especially output, from command execution until change of signal on the output
can be achieved?
2) How much jitter in this
16 matches
Mail list logo
