[Xenomai] problem with rt_task_wait_period

[Xenomai] problem with rt_task_wait_period

[JAY KOTHARI]

Hi,
    I am using rt_task_wait_period in calculating jitter for two of my
task.But it works perfectly for one task while it shows error in
second real time task.I am writing code.Please tell me where am I
going wrong

#include<stdio.h>
#include<signal.h>
#include<unistd.h>
#include<sys/mman.h>
//#include <native/sem.h>

#include<native/task.h>
#include<native/timer.h>
#include<native/pipe.h>

#define TASK_MODE       (T_FPU|T_CPU(0))
#define TASK_STKSZ      4096
#define u_NSEC          1000000

#define SETUP_TICK_NSEC         1000000

#define PERIOD_1        (u_NSEC*1)
#define PERIOD_2        (u_NSEC*2)

#define ONE_SHOT_MODE   1

void rt_task_1(void *cookie)
{       unsigned long overrun1_t;
        int ret;
        int err;
        RTIME systime1=0,systime2=0,expected=0;
        systime2= rt_timer_read();
        ret = rt_task_set_periodic(&task_desc1, TM_NOW, PERIOD_1);
        if(ret<0)
        {
        printf("error1 in rt_task_set_periodic()  %d ...\n",ret); return ;
        }

        expected= systime2 + PERIOD_2;
        err=rt_task_wait_period(&overrun1_t);
      printf("overrun1=%lu\n",overrun1_t);
        if(err<0)
        {perror("task wait error\n");
        }
        systime1 = rt_timer_read();
      printf("actual system time after first task1 wake-up....value
%llu \n",systime1);
      printf(" task1 time%lld \n", systime1-systime2);

      printf("jitter after task1.....%lld\n",systime1-expected);
        expected=systime1;
}

void rt_task_2(void *cookie)
{
int overrun2_t;
int ret,ret1;
        printf("\t task 2 started  \t\n");
        int err,i;
        RTIME systime1=0,systime2=0,expected=0;
        systime2= rt_timer_read();
        ret1 = rt_task_set_periodic(&task_desc1, TM_NOW, PERIOD_2);
        if(ret<0)
        {
        printf("error2 in rt_task_set_periodic()  %d ...\n",ret); return ;
        }
                expected= systime2 +PERIOD_2;
                err=rt_task_wait_period(&overrun2_t);
if(err<0)
{perror("task 2 wait error\n");
 }

        systime1 = rt_timer_read();
printf("jitter after task2.....%lld\n",systime1-expected);

//      printf("\ttask 2 ended\t\n");
//        rt_sem_v(&sem_desc);

}
void catch_signal(int sig)
{printf("task is completed\n");
}
int main(int argc,char* argv[])
{
        int ret;
        signal(SIGTERM,catch_signal);
        signal(SIGINT,catch_signal);

        mlockall(MCL_CURRENT | MCL_FUTURE);

#if ONE_SHOT_MODE == 1
                ret = rt_timer_set_mode(TM_ONESHOT);//sets timer MODE
                printf("timer base in one-shot mode  ***********");
#else
                ret = rt_timer_set_mode(SETUP_TICK_NSEC);
                printf("timer base in periodic mode  *********");
#endif

      ret=rt_task_create(&task_desc1,"rt_task_1",TASK_STKSZ,5,TASK_MODE);
        rt_task_start(&task_desc1,&rt_task_1,NULL);
   pause();
          ret = rt_task_delete(&task_desc1);
    ret=rt_task_create(&task_desc2,"rt_task_2",TASK_STKSZ,4,TASK_MODE);
        rt_task_start(&task_desc2,&rt_task_2,NULL);
    pause();
        ret = rt_task_delete(&task_desc2);

}

Re: [Xenomai] problem with rt_task_wait_period

[Gilles Chanteperdrix]

On 09/19/2014 01:33 PM, JAY KOTHARI wrote:
> Hi,
>     I am using rt_task_wait_period in calculating jitter for two of my
> task.But it works perfectly for one task while it shows error in
> second real time task.I am writing code.Please tell me where am I
> going wrong
> 
> #include<stdio.h>
> #include<signal.h>
> #include<unistd.h>
> #include<sys/mman.h>
> //#include <native/sem.h>
> 
> #include<native/task.h>
> #include<native/timer.h>
> #include<native/pipe.h>
> 
> #define TASK_MODE       (T_FPU|T_CPU(0))
> #define TASK_STKSZ      4096
> #define u_NSEC          1000000
> 
> #define SETUP_TICK_NSEC         1000000
> 
> #define PERIOD_1        (u_NSEC*1)
> #define PERIOD_2        (u_NSEC*2)
> 
> #define ONE_SHOT_MODE   1
> 
> void rt_task_1(void *cookie)
> {       unsigned long overrun1_t;
>         int ret;
>         int err;
>         RTIME systime1=0,systime2=0,expected=0;
>         systime2= rt_timer_read();
>         ret = rt_task_set_periodic(&task_desc1, TM_NOW, PERIOD_1);
>         if(ret<0)
>         {
>         printf("error1 in rt_task_set_periodic()  %d ...\n",ret); return ;
>         }
> 
>         expected= systime2 + PERIOD_2;

This looks wrong, you want systime2 + PERIOD_1 here.

>         err=rt_task_wait_period(&overrun1_t);
>       printf("overrun1=%lu\n",overrun1_t);
>         if(err<0)
>         {perror("task wait error\n");
>         }
>         systime1 = rt_timer_read();
>       printf("actual system time after first task1 wake-up....value
> %llu \n",systime1);
>       printf(" task1 time%lld \n", systime1-systime2);
> 
>       printf("jitter after task1.....%lld\n",systime1-expected);

The printf here will cause the task to switch to secondary mode, unless
you compile for the posix skin (in addition to the native skin), and
will cause jitter for the next release point.


-- 
                                                                Gilles.

Re: [Xenomai] problem with rt_task_wait_period

[Gilles Chanteperdrix]

On 09/19/2014 01:50 PM, JAY KOTHARI wrote:
> Thank you,But how can I set posix skin? How to print in primary
> mode(i.e. without printf). As I am new to xenomai so I may say silly
> question.Sorry for that.

Please:
- do not send me private mails, use the mailing list
- do not top-post
- quote the part of the answer to which you are replying, not the whole
answer.

As for the answer to your question, see:
http://bit.ly/1uLM2l0


-- 
                                                                Gilles.

[Xenomai] clock_gettime cause runaway thread

[huy-cong.vu]

Hello everyone,
I'm currently working with Xenomai in my company's project using RTNet as
realtime ethernet driver to communicate with Elmo card via EtherCAT
protocol and SOEM as master library.

I'm using Linux 3.8.13 patched with Xenomai 2.6.3.

I'm debugging a simple test which is a cycle of send & receive data with a
frequency of 1 kHz. The test runs fine for a quite long time (30 mins in
average), but still throws runaway thread after a certain time.

My loop is a periodic thread:

rt_task_set_periodic(rt_task_self(), TM_NOW, 1000000);
while(1){
rt_task_wait_period();
ec_send_processdata();     //SOEM function
ec_receive_processdata();  //SOEM function
}

With SIGDEBUG & gdb, the error seems to start from clock_gettime (when
ec_receive_processdata is called) with CLOCK_MONOTONIC, change to
CLOCK_REALTIME reproduces the same issue. My processor is x86_64, I heard
that the High Resolution Timer of Linux kernel is not supported for
processor 64 bits, this could be the reason for such behavior?

Reading this mailing conversation:
http://www.xenomai.org/pipermail/xenomai/2013-March/028021.html, I
understand that I have to put thread on sleep while not running, but even
with rt_task_sleep inserted, is not better. I don't know neither if
something could've occupied 100% CPU (while my task normally runs with
0.2% CPU occupied).

I'm running out of ideas for now. I'm very grateful for any suggestions.
Thank you in advance! (and sorry for my english)

Huy Cong VU

Re: [Xenomai] clock_gettime cause runaway thread

[Gilles Chanteperdrix]

On 09/19/2014 06:11 PM, huy-cong.vu@wandercraft.eu wrote:
> Hello everyone,
> I'm currently working with Xenomai in my company's project using RTNet as
> realtime ethernet driver to communicate with Elmo card via EtherCAT
> protocol and SOEM as master library.

Please ask this question again without replying to an unrelated message.
This will avoid the mailing list archives to become a mess.


-- 
                                                                Gilles.

Re: [Xenomai] clock_gettime cause runaway thread

[Philippe Gerum]

On 09/19/2014 06:11 PM, huy-cong.vu@wandercraft.eu wrote:
> Hello everyone,
> I'm currently working with Xenomai in my company's project using RTNet as
> realtime ethernet driver to communicate with Elmo card via EtherCAT
> protocol and SOEM as master library.
> 
> I'm using Linux 3.8.13 patched with Xenomai 2.6.3.
> 
> I'm debugging a simple test which is a cycle of send & receive data with a
> frequency of 1 kHz. The test runs fine for a quite long time (30 mins in
> average), but still throws runaway thread after a certain time.
> 
> My loop is a periodic thread:
> 
> rt_task_set_periodic(rt_task_self(), TM_NOW, 1000000);
> while(1){
> rt_task_wait_period();
> ec_send_processdata();     //SOEM function
> ec_receive_processdata();  //SOEM function
> }
> 
> With SIGDEBUG & gdb, the error seems to start from clock_gettime (when
> ec_receive_processdata is called) with CLOCK_MONOTONIC, change to
> CLOCK_REALTIME reproduces the same issue. My processor is x86_64, I heard
> that the High Resolution Timer of Linux kernel is not supported for
> processor 64 bits, this could be the reason for such behavior?
> 

I never heard about the restriction you are referring to.

> Reading this mailing conversation:
> http://www.xenomai.org/pipermail/xenomai/2013-March/028021.html, I
> understand that I have to put thread on sleep while not running, but even
> with rt_task_sleep inserted, is not better. I don't know neither if
> something could've occupied 100% CPU (while my task normally runs with
> 0.2% CPU occupied).
> 
> I'm running out of ideas for now. I'm very grateful for any suggestions.
> Thank you in advance! (and sorry for my english)
> 

What about testing the return value of rt_task_wait_period()?

-- 
Philippe.

Re: [Xenomai] clock_gettime cause runaway thread

[Philippe Gerum]

On 09/19/2014 06:53 PM, Philippe Gerum wrote:
> On 09/19/2014 06:11 PM, huy-cong.vu@wandercraft.eu wrote:
>> Hello everyone,
>> I'm currently working with Xenomai in my company's project using RTNet as
>> realtime ethernet driver to communicate with Elmo card via EtherCAT
>> protocol and SOEM as master library.
>>
>> I'm using Linux 3.8.13 patched with Xenomai 2.6.3.
>>
>> I'm debugging a simple test which is a cycle of send & receive data with a
>> frequency of 1 kHz. The test runs fine for a quite long time (30 mins in
>> average), but still throws runaway thread after a certain time.
>>
>> My loop is a periodic thread:
>>
>> rt_task_set_periodic(rt_task_self(), TM_NOW, 1000000);
>> while(1){
>> rt_task_wait_period();
>> ec_send_processdata();     //SOEM function
>> ec_receive_processdata();  //SOEM function
>> }
>>
>> With SIGDEBUG & gdb, the error seems to start from clock_gettime (when
>> ec_receive_processdata is called) with CLOCK_MONOTONIC, change to
>> CLOCK_REALTIME reproduces the same issue. My processor is x86_64, I heard
>> that the High Resolution Timer of Linux kernel is not supported for
>> processor 64 bits, this could be the reason for such behavior?
>>
> 
> I never heard about the restriction you are referring to.
> 

If you are referring to the deadlock issue when calling the regular
glibc services such as gettimeofday/clock_gettime from rt mode, then
this is not a 64bit specific issue. You need to call the clock_gettime()
service from the Xenomai POSIX API, asking for CLOCK_HOST_REALTIME.

-- 
Philippe.

Re: [Xenomai] clock_gettime cause runaway thread

[huy-cong.vu]

> On 09/19/2014 06:53 PM, Philippe Gerum wrote:
>> On 09/19/2014 06:11 PM, huy-cong.vu@wandercraft.eu wrote:
>>> Hello everyone,
>>> I'm currently working with Xenomai in my company's project using RTNet
>>> as
>>> realtime ethernet driver to communicate with Elmo card via EtherCAT
>>> protocol and SOEM as master library.
>>>
>>> I'm using Linux 3.8.13 patched with Xenomai 2.6.3.
>>>
>>> I'm debugging a simple test which is a cycle of send & receive data
>>> with a
>>> frequency of 1 kHz. The test runs fine for a quite long time (30 mins
>>> in
>>> average), but still throws runaway thread after a certain time.
>>>
>>> My loop is a periodic thread:
>>>
>>> rt_task_set_periodic(rt_task_self(), TM_NOW, 1000000);
>>> while(1){
>>> rt_task_wait_period();
>>> ec_send_processdata();     //SOEM function
>>> ec_receive_processdata();  //SOEM function
>>> }
>>>
>>> With SIGDEBUG & gdb, the error seems to start from clock_gettime (when
>>> ec_receive_processdata is called) with CLOCK_MONOTONIC, change to
>>> CLOCK_REALTIME reproduces the same issue. My processor is x86_64, I
>>> heard
>>> that the High Resolution Timer of Linux kernel is not supported for
>>> processor 64 bits, this could be the reason for such behavior?
>>>
>>
>> I never heard about the restriction you are referring to.
>>
>
> If you are referring to the deadlock issue when calling the regular
> glibc services such as gettimeofday/clock_gettime from rt mode, then
> this is not a 64bit specific issue. You need to call the clock_gettime()
> service from the Xenomai POSIX API, asking for CLOCK_HOST_REALTIME.
>
> --
> Philippe.
>

Hello,
I tried to call clock_gettime() with CLOCK_HOST_REALTIME, but my hardware
fall directly into error. If I understand correctly, CLOCK_HOST_REALTIME
is called from the POSIX skin, a.k.a secondary mode, while my application
need to run at primary mode, that's why it stops running right away. Using
CLOCK_MONOTONIC & CLOCK_REALTIME was fine. What is the main difference
between these timers?

Huy Cong VU

Re: [Xenomai] clock_gettime cause runaway thread

[Philippe Gerum]

On 09/22/2014 12:25 PM, huy-cong.vu@wandercraft.eu wrote:
>> On 09/19/2014 06:53 PM, Philippe Gerum wrote:
>>> On 09/19/2014 06:11 PM, huy-cong.vu@wandercraft.eu wrote:
>>>> Hello everyone,
>>>> I'm currently working with Xenomai in my company's project using RTNet
>>>> as
>>>> realtime ethernet driver to communicate with Elmo card via EtherCAT
>>>> protocol and SOEM as master library.
>>>>
>>>> I'm using Linux 3.8.13 patched with Xenomai 2.6.3.
>>>>
>>>> I'm debugging a simple test which is a cycle of send & receive data
>>>> with a
>>>> frequency of 1 kHz. The test runs fine for a quite long time (30 mins
>>>> in
>>>> average), but still throws runaway thread after a certain time.
>>>>
>>>> My loop is a periodic thread:
>>>>
>>>> rt_task_set_periodic(rt_task_self(), TM_NOW, 1000000);
>>>> while(1){
>>>> rt_task_wait_period();
>>>> ec_send_processdata();     //SOEM function
>>>> ec_receive_processdata();  //SOEM function
>>>> }
>>>>
>>>> With SIGDEBUG & gdb, the error seems to start from clock_gettime (when
>>>> ec_receive_processdata is called) with CLOCK_MONOTONIC, change to
>>>> CLOCK_REALTIME reproduces the same issue. My processor is x86_64, I
>>>> heard
>>>> that the High Resolution Timer of Linux kernel is not supported for
>>>> processor 64 bits, this could be the reason for such behavior?
>>>>
>>>
>>> I never heard about the restriction you are referring to.
>>>
>>
>> If you are referring to the deadlock issue when calling the regular
>> glibc services such as gettimeofday/clock_gettime from rt mode, then
>> this is not a 64bit specific issue. You need to call the clock_gettime()
>> service from the Xenomai POSIX API, asking for CLOCK_HOST_REALTIME.
>>
>> --
>> Philippe.
>>
> 
> Hello,
> I tried to call clock_gettime() with CLOCK_HOST_REALTIME, but my hardware
> fall directly into error. If I understand correctly, CLOCK_HOST_REALTIME
> is called from the POSIX skin, a.k.a secondary mode,

The POSIX skin does not imply secondary mode, quite the contrary: it
aims at running POSIX services in primary mode. Secondary mode means
regular linux mode, not controlled by the Xenomai co-kernel.

 while my application

No, it runs from primary mode. It has been designed with that intent in
mind, precisely because the way gettimeofday/clock_gettime are
implemented over the vsyscall mechanism makes them incompatible with any
usage from primary mode.

> need to run at primary mode, that's why it stops running right away. Using
> CLOCK_MONOTONIC & CLOCK_REALTIME was fine. What is the main difference
> between these timers?

CLOCK_REALTIME served by the POSIX skin uses the Xenomai idea of time
(epoch). This is not in sync with the epoch used by the regular kernel,
hence HOST_REALTIME. CLOCK_MONOTONIC served by the POSIX skin is the
same as rt_timer_tsc(), i.e. a raw tick count maintained by some high
precision timer we use on the hardware platform, monotonically increasing.

You should really make sure to use the right clock_gettime(), i.e. the
one from libpthread_rt.
http://xenomai.org/2014/08/porting-a-linux-application-to-xenomai-dual-kernel/

-- 
Philippe.

Re: [Xenomai] clock_gettime cause runaway thread

[huy-cong.vu]

> On 09/22/2014 12:25 PM, huy-cong.vu@wandercraft.eu wrote:
>>> On 09/19/2014 06:53 PM, Philippe Gerum wrote:
>>>> On 09/19/2014 06:11 PM, huy-cong.vu@wandercraft.eu wrote:
>>>>> Hello everyone,
>>>>> I'm currently working with Xenomai in my company's project using
>>>>> RTNet
>>>>> as
>>>>> realtime ethernet driver to communicate with Elmo card via EtherCAT
>>>>> protocol and SOEM as master library.
>>>>>
>>>>> I'm using Linux 3.8.13 patched with Xenomai 2.6.3.
>>>>>
>>>>> I'm debugging a simple test which is a cycle of send & receive data
>>>>> with a
>>>>> frequency of 1 kHz. The test runs fine for a quite long time (30 mins
>>>>> in
>>>>> average), but still throws runaway thread after a certain time.
>>>>>
>>>>> My loop is a periodic thread:
>>>>>
>>>>> rt_task_set_periodic(rt_task_self(), TM_NOW, 1000000);
>>>>> while(1){
>>>>> rt_task_wait_period();
>>>>> ec_send_processdata();     //SOEM function
>>>>> ec_receive_processdata();  //SOEM function
>>>>> }
>>>>>
>>>>> With SIGDEBUG & gdb, the error seems to start from clock_gettime
>>>>> (when
>>>>> ec_receive_processdata is called) with CLOCK_MONOTONIC, change to
>>>>> CLOCK_REALTIME reproduces the same issue. My processor is x86_64, I
>>>>> heard
>>>>> that the High Resolution Timer of Linux kernel is not supported for
>>>>> processor 64 bits, this could be the reason for such behavior?
>>>>>
>>>>
>>>> I never heard about the restriction you are referring to.
>>>>
>>>
>>> If you are referring to the deadlock issue when calling the regular
>>> glibc services such as gettimeofday/clock_gettime from rt mode, then
>>> this is not a 64bit specific issue. You need to call the
>>> clock_gettime()
>>> service from the Xenomai POSIX API, asking for CLOCK_HOST_REALTIME.
>>>
>>> --
>>> Philippe.
>>>
>>
>> Hello,
>> I tried to call clock_gettime() with CLOCK_HOST_REALTIME, but my
>> hardware
>> fall directly into error. If I understand correctly, CLOCK_HOST_REALTIME
>> is called from the POSIX skin, a.k.a secondary mode,
>
> The POSIX skin does not imply secondary mode, quite the contrary: it
> aims at running POSIX services in primary mode. Secondary mode means
> regular linux mode, not controlled by the Xenomai co-kernel.
>
>  while my application
>
> No, it runs from primary mode. It has been designed with that intent in
> mind, precisely because the way gettimeofday/clock_gettime are
> implemented over the vsyscall mechanism makes them incompatible with any
> usage from primary mode.
>
>> need to run at primary mode, that's why it stops running right away.
>> Using
>> CLOCK_MONOTONIC & CLOCK_REALTIME was fine. What is the main difference
>> between these timers?
>
> CLOCK_REALTIME served by the POSIX skin uses the Xenomai idea of time
> (epoch). This is not in sync with the epoch used by the regular kernel,
> hence HOST_REALTIME. CLOCK_MONOTONIC served by the POSIX skin is the
> same as rt_timer_tsc(), i.e. a raw tick count maintained by some high
> precision timer we use on the hardware platform, monotonically increasing.
>
> You should really make sure to use the right clock_gettime(), i.e. the
> one from libpthread_rt.
> http://xenomai.org/2014/08/porting-a-linux-application-to-xenomai-dual-kernel/
>
> --
> Philippe.
>

Thanks Philippe,
I'm following the porting guide that you suggest. One small question: Is
this possible to mix between POSIX & native skin of Xenomai? Because most
of my app's code is in native skin, but some services are only accessible
via POSIX skins (like setschedparam). Is there a risk in mixing these 2?
And which are the flags need to be passing to the compiler to get a good
mixes?

Huy Cong VU