[Xenomai-help] timing, scheduling. some theory?

[Xenomai-help] timing, scheduling. some theory?

[roland Tollenaar]

Hi,

Ok I have the framework of my application up. Qt, user-interface, 2
tasks running in parallel, one @ 1ms the other @ 2ms.

Next step is to start incorporating the work that must be performed in
the tasks but before I do so it will be useful to have some
understanding of how the scheduling takes place.

I fear the above might not convey my question clearly. I find it hard
to explain exactly what I mean by this so I will pose the question
differently.

What does

rt_task_wait_period();

do exactly? It will be followed by the work that must be done in the
task but does the work get performed while rt_task_wait_period(); is
"waiting" or does nothing happen while the program is on that call?

In the latter case I will have no real control over when the task is
complete. On a fast machine the task will be finished sooner than on a
slower machine.

For example say I am setting outputs based on calculations (e.g. QR
decompositions, singular value decompositions etc) processing certain
inputs. If I read the inputs  first after calling
rt_task_wait_period() then  do the calculations and finally set the
outputs the time difference between reading the inputs and setting
outputs will (in the best case) depend on the the speed of the
machine.

In this scenario there are obviously more optimal manners to structure
the program but I am using it as an example.

Anyhow is there any documentation that elucidates these aspects of xenomai?

Regards,

Roland.

Re: [Xenomai-help] timing, scheduling. some theory?

[Gilles Chanteperdrix]

roland Tollenaar wrote:
 > Hi,
 > 
 > Ok I have the framework of my application up. Qt, user-interface, 2
 > tasks running in parallel, one @ 1ms the other @ 2ms.
 > 
 > Next step is to start incorporating the work that must be performed in
 > the tasks but before I do so it will be useful to have some
 > understanding of how the scheduling takes place.
 > 
 > I fear the above might not convey my question clearly. I find it hard
 > to explain exactly what I mean by this so I will pose the question
 > differently.
 > 
 > What does
 > 
 > rt_task_wait_period();
 > 
 > do exactly? It will be followed by the work that must be done in the
 > task but does the work get performed while rt_task_wait_period(); is
 > "waiting" or does nothing happen while the program is on that call?
 > 
 > In the latter case I will have no real control over when the task is
 > complete. On a fast machine the task will be finished sooner than on a
 > slower machine.
 > 
 > For example say I am setting outputs based on calculations (e.g. QR
 > decompositions, singular value decompositions etc) processing certain
 > inputs. If I read the inputs  first after calling
 > rt_task_wait_period() then  do the calculations and finally set the
 > outputs the time difference between reading the inputs and setting
 > outputs will (in the best case) depend on the the speed of the
 > machine.
 > 
 > In this scenario there are obviously more optimal manners to structure
 > the program but I am using it as an example.
 > 
 > Anyhow is there any documentation that elucidates these aspects of xenomai?

Xenomai kernel implements the so-called "FIFO" scheduling policy, that
is, the task which runs at any time is the task with the highest
priority that has been ready for the longest time. Calling
rt_task_wait_period suspends the calling task, and let other tasks
run. 

If I understand correctly, what you want is to set some outputs at some
precise deadline, I see two ways to do what you want:
* either the time when you compute the output has no importance, and the
  only thing that matters is when you set the output, in which case you
  can call rt_task_wait_period right before setting the outputs, your
  task will do
  compute next output
  go to sleep
  set output
  compute next output
  go to sleep
  set output
  etc...

* or the time between reading input and setting output has to be as
  fixed as possible, in which case what you will have to do is to
  calibrate the WCET (worst case execution time) of the computations on
  the machine you are running, setup rt_task_set_periodic so that your
  task is woken up at (deadline - WCET), and in each loop, do the
  computations, then busy wait until the deadline then set the
  output. In order to busy wait, you may use rt_timer_tsc.
 

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] timing, scheduling. some theory?

[roland Tollenaar]

Hi

> Xenomai kernel implements the so-called "FIFO" scheduling policy, that
> is, the task which runs at any time is the task with the highest
> priority that has been ready for the longest time. Calling
> rt_task_wait_period suspends the calling task, and let other tasks
> run.
>
> If I understand correctly, what you want is to set some outputs at some
You understand correctly.

> precise deadline, I see two ways to do what you want:
> * either the time when you compute the output has no importance, and the
>   only thing that matters is when you set the output, in which case you
>   can call rt_task_wait_period right before setting the outputs, your
>   task will do
>   compute next output
>   go to sleep
>   set output
>   compute next output
>   go to sleep
>   set output
>   etc...
Actually this is exactly what I had in mind only it is important
(discrete state space controller computations) that the input is also
read at exact intervals. So maybe:

compute next output k+1
go to sleep
read input for k+2 computations
set output k+1
compute next output k+2
go to sleep
read input for k+3 computations
set output k+2
>   etc...

> * or the time between reading input and setting output has to be as
>   fixed as possible, in which case what you will have to do is to
>   calibrate the WCET (worst case execution time) of the computations on
>   the machine you are running, setup rt_task_set_periodic so that your
>   task is woken up at (deadline - WCET), and in each loop, do the
>   computations, then busy wait until the deadline then set the
>   output. In order to busy wait, you may use rt_timer_tsc.

Off hand I am not exactly sure why this second technique would give me
a more fixed interval between reading input and writing output than
the modified technique 1 I suggest above?

Obviously one problem i have is the duration of obtaining input and
setting output. Both will be coming in and going out over a CANOpen
connection but from the moment the messages are on the bus I have no
control over what happens. Of course this has nothing to do with
xenomai but only with the deterministic characteristics of the CAN
protocol. And AFAIK that is not good?


Thanks.

Roland.


>
>
> --
>
>
>                                             Gilles Chanteperdrix.
>

Re: [Xenomai-help] timing, scheduling. some theory?

[Gilles Chanteperdrix]

roland Tollenaar wrote:
 > Hi
 > 
 > > Xenomai kernel implements the so-called "FIFO" scheduling policy, that
 > > is, the task which runs at any time is the task with the highest
 > > priority that has been ready for the longest time. Calling
 > > rt_task_wait_period suspends the calling task, and let other tasks
 > > run.
 > >
 > > If I understand correctly, what you want is to set some outputs at some
 > You understand correctly.
 > 
 > > precise deadline, I see two ways to do what you want:
 > > * either the time when you compute the output has no importance, and the
 > >   only thing that matters is when you set the output, in which case you
 > >   can call rt_task_wait_period right before setting the outputs, your
 > >   task will do
 > >   compute next output
 > >   go to sleep
 > >   set output
 > >   compute next output
 > >   go to sleep
 > >   set output
 > >   etc...
 > Actually this is exactly what I had in mind only it is important
 > (discrete state space controller computations) that the input is also
 > read at exact intervals. So maybe:
 > 
 > compute next output k+1
 > go to sleep
 > read input for k+2 computations
 > set output k+1
 > compute next output k+2
 > go to sleep
 > read input for k+3 computations
 > set output k+2
 > >   etc...
 > 
 > > * or the time between reading input and setting output has to be as
 > >   fixed as possible, in which case what you will have to do is to
 > >   calibrate the WCET (worst case execution time) of the computations on
 > >   the machine you are running, setup rt_task_set_periodic so that your
 > >   task is woken up at (deadline - WCET), and in each loop, do the
 > >   computations, then busy wait until the deadline then set the
 > >   output. In order to busy wait, you may use rt_timer_tsc.
 > 
 > Off hand I am not exactly sure why this second technique would give me
 > a more fixed interval between reading input and writing output than
 > the modified technique 1 I suggest above?

I supposed you had to read input k+1 after having set output k

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] timing, scheduling. some theory?

[Wolfgang Grandegger]

roland Tollenaar wrote:
> Hi
> 
>> Xenomai kernel implements the so-called "FIFO" scheduling policy, that
>> is, the task which runs at any time is the task with the highest
>> priority that has been ready for the longest time. Calling
>> rt_task_wait_period suspends the calling task, and let other tasks
>> run.
>>
>> If I understand correctly, what you want is to set some outputs at some
> You understand correctly.
> 
>> precise deadline, I see two ways to do what you want:
>> * either the time when you compute the output has no importance, and the
>>   only thing that matters is when you set the output, in which case you
>>   can call rt_task_wait_period right before setting the outputs, your
>>   task will do
>>   compute next output
>>   go to sleep
>>   set output
>>   compute next output
>>   go to sleep
>>   set output
>>   etc...
> Actually this is exactly what I had in mind only it is important
> (discrete state space controller computations) that the input is also
> read at exact intervals. So maybe:
> 
> compute next output k+1
> go to sleep
> read input for k+2 computations
> set output k+1
> compute next output k+2
> go to sleep
> read input for k+3 computations
> set output k+2
>>   etc...
> 
>> * or the time between reading input and setting output has to be as
>>   fixed as possible, in which case what you will have to do is to
>>   calibrate the WCET (worst case execution time) of the computations on
>>   the machine you are running, setup rt_task_set_periodic so that your
>>   task is woken up at (deadline - WCET), and in each loop, do the
>>   computations, then busy wait until the deadline then set the
>>   output. In order to busy wait, you may use rt_timer_tsc.
> 
> Off hand I am not exactly sure why this second technique would give me
> a more fixed interval between reading input and writing output than
> the modified technique 1 I suggest above?
> 
> Obviously one problem i have is the duration of obtaining input and
> setting output. Both will be coming in and going out over a CANOpen
> connection but from the moment the messages are on the bus I have no
> control over what happens. Of course this has nothing to do with
> xenomai but only with the deterministic characteristics of the CAN
> protocol. And AFAIK that is not good?

What do you mean with a CANopen connection? CANopen is a protocol stack 
which must run on your system to communicate with CANopen nodes through 
the CAN bus.

Wolfgang.