What causes the latency of the rt_task_yield() API?

What causes the latency of the rt_task_yield() API?

[김세현(Sehyun Kim) 연구원 두산로보틱스]

Currently, I am using xenomai 2.6.5 version and am working on changing it to 3.0.8 version.

When using version 3.0.8, there is a delay of about 4ms when using rt_task_yield()

After creating and starting multiple tasks, rt_task_yield() is still running on all tasks.

This is a problem that did not occur in the 2.6.5 version.

Is there anything I need to set in version 3.0.8?
If not, is it a kernel version issue? (The current kernel version is 4.1.18.)
If not, is there an API that can replace rt_task_yield() ?


- previous version

Xubuntu : Xubuntu-17.10.1

Linux kernel : Linux-3.14.44

Xenomai : Xenomai-2.6.5

Xenomai Ipipe : ipipe-core-3.14.44-x86-12.patch



- current version

Xubuntu : Xubuntu 18.04 LTS

Linux kernel : Linux kernel 4.1.18

Xenomai : Xenomai-3.0.8

Xenomai Ipipe : ipipe-core-4.1.18-x86-7.patch


Look forward to hearing from you.
Best regards.






SE HYUN KIM
Researcher, R&D Center Control Framework Team

Email : sehyun2.kim@doosan.com
Web : www.doosanrobotics.com






This e-mail and any attachments herein may contain confidential or privileged information and is for the exclusive use of the intended recipient(s) named above. If you are not the intended recipient(s), you should not disseminate, distribute, retain, copy or otherwise use any information contained herein. If you have received this e-mail in error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments. Our company does not guarantee this e-mail is secure or free from viruses.
이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[김세현(Sehyun Kim) 연구원 두산로보틱스]

If rt_task_yield() works normally, what is the delay time?





From: Chen, Hongzhan <hongzhan.chen@intel.com>
Sent: Tuesday, August 23, 2022 9:51 AM
To: 김세현(Sehyun Kim) 연구원 두산로보틱스 <sehyun2.kim@doosan.com>; xenomai@xenomai.org
Cc: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
Subject: RE: What causes the latency of the rt_task_yield() API?

>-----Original Message-----
>From: ???(Sehyun Kim) ??? ?????? mailto:sehyun2.kim@doosan.com
>Sent: Tuesday, August 23, 2022 8:11 AM
>To: mailto:xenomai@xenomai.org
>Cc: ???(Dongjoo Kim) ????? ?????? mailto:dongjoo5.kim@doosan.com
>Subject: What causes the latency of the rt_task_yield() API?
>
>
>Currently, I am using xenomai 2.6.5 version and am working on changing it to 3.0.8 version.
>
>When using version 3.0.8, there is a delay of about 4ms when using rt_task_yield()
>
>After creating and starting multiple tasks, rt_task_yield() is still running on all tasks.
>
>This is a problem that did not occur in the 2.6.5 version.
>
>Is there anything I need to set in version 3.0.8?
>If not, is it a kernel version issue? (The current kernel version is 4.1.18.)
>If not, is there an API that can replace rt_task_yield() ?

I suggest you may make use of  ftrace  and enable enough events for example sched events to check what the difference
happen between these two cases in cobalt core and help narrow down the issue.  I do not know what code difference may cause
such issue.

Regards

Hongzhan Chen
>
>
>- previous version
>
>Xubuntu : Xubuntu-17.10.1
>
>Linux kernel : Linux-3.14.44
>
>Xenomai : Xenomai-2.6.5
>
>Xenomai Ipipe : ipipe-core-3.14.44-x86-12.patch
>
>
>
>- current version
>
>Xubuntu : Xubuntu 18.04 LTS
>
>Linux kernel : Linux kernel 4.1.18
>
>Xenomai : Xenomai-3.0.8
>
>Xenomai Ipipe : ipipe-core-4.1.18-x86-7.patch
>
>
>Look forward to hearing from you.
>Best regards.
>
>
>
>
>
>
>SE HYUN KIM
>Researcher, R&D Center Control Framework Team
>
>Email : mailto:sehyun2.kim@doosan.com
>Web : http://secure-web.cisco.com/1cJso98gz_hnGZGMPEAQN0liSZnDURNopv4Z1EnCyAyZNMAK72pG7n_2ENIEMBQt86ogrjZD4WrvNDMYzlo_tkhG-7S6Wr-aSk-7AdOM_TvC8tEDwfzhrndK_My0d8lzyBzH3V2OlLEsmGfoql3Mgt0BV7NxZ6VofyHVVYk5H8Bh5HyavaD0nBABq7VSK0bimlA2BYnpaLCjuJABCtq_rg0djwVf8nfOLP7nirwDevPHOSSHjyP3EMNqoXWgnyuz0k9aaMh_yRqMhu0ERTgy8Ipn9S1v4wjLm80EHV4oUHh9EIQi_Ez79fvAD1Fu7nd62/http%3A%2F%2Fwww.doosanrobotics.com


This e-mail and any attachments herein may contain confidential or privileged information and is for the exclusive use of the intended recipient(s) named above. If you are not the intended recipient(s), you should not disseminate, distribute, retain, copy or otherwise use any information contained herein. If you have received this e-mail in error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments. Our company does not guarantee this e-mail is secure or free from viruses.
이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[김동주(Dongjoo Kim) 책임연구원 두산로보틱스]

Dear Xenomai.org, Chen, Hongzhan

I'm dong joo.

Thank you for contacting us regarding our question.

We are interesting about Xenomai Cobalt.
But, We are not used to apply Xenomai Cobalt.
So, We have studied about Xenomai Cobalt.


Could you explain our questions about Xenomai Cobalt as like below?

If you reply to us our questions, It's very helpful to understand about Xenomai Cobalt.


Our issue about Xenomai 3.0.8 ( Linux kernel 4.1.18, ipipe-core-4.1.18-x86-9.patch )

Normal : Xenomai 2.6.5 ( Linux kernel 3.14.44, ipipe-core-3.14.44-x86-12.patch )


While ( 1 )
{
        A function ();
        -> A function is printed every 20us by using rt_printf function
        rt_task_yield () ;
}


Issue : Xenomai 3.0.8 ( Linux kernel 4.1.18, ipipe-core-4.1.18-x86-9.patch )

While ( 1 )
{
        A function ();
        -> A function is printed every 4ms by using rt_printf function.
        rt_task_yield () ;
}


1.
What is Xenomai Cobalt Kernel as like ipipe patch ?

If the system call is occurred by the rt_task_yield function in the user space,
Is Xenomai Cobalt Kernel to schedule a Task without Linux kernel scheduler ?
If not, Is Xenomai Cobalt Kernel to schedule a Task with Linux kernel scheduler ?

I'm confused the action of  Xenomai Cobalt Kernel.
Is Xenomai Cobalt Kernel a new Task Scheduler ?
If not, Do Xenomai Cobalt Kernel use Linux kernel scheduler ?

If we use rt_task_yield function in the user space or sched_yield function in the user space,
Which is the difference kernel space's action after system call ?


2.
As I know, Ftrace is used to debug about linux kernel scheduler.
Do the Xenomai Cobalt kernel to use Ftrace for debugging ?


3.
Could you share to us the function in the kernel space after system call if we use rt_task_yield in the user space ?


For example,
Is the the function in the kernel space difference if we use __RT ( rt_task_yield ) in the user space or _STD ( native task_yield ) in the user space ?


#define COBALT_DECL(T, P)       \
        __typeof__(T) __RT(P);  \
        __typeof__(T) __STD(P);/
        __typeof__(T) __WRAP(P)


Thanks.

-----Original Message-----
From: 김세현(Sehyun Kim) 연구원 두산로보틱스 <sehyun2.kim@doosan.com>
Sent: Wednesday, August 24, 2022 6:14 PM
To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
Cc: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
Subject: RE: What causes the latency of the rt_task_yield() API?


If rt_task_yield() works normally, what is the delay time?





From: Chen, Hongzhan <hongzhan.chen@intel.com>
Sent: Tuesday, August 23, 2022 9:51 AM
To: 김세현(Sehyun Kim) 연구원 두산로보틱스 <sehyun2.kim@doosan.com>; xenomai@xenomai.org
Cc: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
Subject: RE: What causes the latency of the rt_task_yield() API?

>-----Original Message-----
>From: ???(Sehyun Kim) ??? ?????? mailto:sehyun2.kim@doosan.com
>Sent: Tuesday, August 23, 2022 8:11 AM
>To: mailto:xenomai@xenomai.org
>Cc: ???(Dongjoo Kim) ????? ?????? mailto:dongjoo5.kim@doosan.com
>Subject: What causes the latency of the rt_task_yield() API?
>
>
>Currently, I am using xenomai 2.6.5 version and am working on changing it to 3.0.8 version.
>
>When using version 3.0.8, there is a delay of about 4ms when using
>rt_task_yield()
>
>After creating and starting multiple tasks, rt_task_yield() is still running on all tasks.
>
>This is a problem that did not occur in the 2.6.5 version.
>
>Is there anything I need to set in version 3.0.8?
>If not, is it a kernel version issue? (The current kernel version is
>4.1.18.) If not, is there an API that can replace rt_task_yield() ?

I suggest you may make use of  ftrace  and enable enough events for example sched events to check what the difference happen between these two cases in cobalt core and help narrow down the issue.  I do not know what code difference may cause such issue.

Regards

Hongzhan Chen
>
>
>- previous version
>
>Xubuntu : Xubuntu-17.10.1
>
>Linux kernel : Linux-3.14.44
>
>Xenomai : Xenomai-2.6.5
>
>Xenomai Ipipe : ipipe-core-3.14.44-x86-12.patch
>
>
>
>- current version
>
>Xubuntu : Xubuntu 18.04 LTS
>
>Linux kernel : Linux kernel 4.1.18
>
>Xenomai : Xenomai-3.0.8
>
>Xenomai Ipipe : ipipe-core-4.1.18-x86-7.patch
>
>
>Look forward to hearing from you.
>Best regards.
>
>
>
>
>
>
>SE HYUN KIM
>Researcher, R&D Center Control Framework Team
>
>Email : mailto:sehyun2.kim@doosan.com
>Web :
>http://secure-web.cisco.com/1cJso98gz_hnGZGMPEAQN0liSZnDURNopv4Z1EnCyAy
>ZNMAK72pG7n_2ENIEMBQt86ogrjZD4WrvNDMYzlo_tkhG-7S6Wr-aSk-7AdOM_TvC8tEDwf
>zhrndK_My0d8lzyBzH3V2OlLEsmGfoql3Mgt0BV7NxZ6VofyHVVYk5H8Bh5HyavaD0nBABq
>7VSK0bimlA2BYnpaLCjuJABCtq_rg0djwVf8nfOLP7nirwDevPHOSSHjyP3EMNqoXWgnyuz
>0k9aaMh_yRqMhu0ERTgy8Ipn9S1v4wjLm80EHV4oUHh9EIQi_Ez79fvAD1Fu7nd62/http%
>3A%2F%2Fwww.doosanrobotics.com


This e-mail and any attachments herein may contain confidential or privileged information and is for the exclusive use of the intended recipient(s) named above. If you are not the intended recipient(s), you should not disseminate, distribute, retain, copy or otherwise use any information contained herein. If you have received this e-mail in error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments. Our company does not guarantee this e-mail is secure or free from viruses.
이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[Chen, Hongzhan]

>-----Original Message-----
>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com> 
>Sent: Thursday, August 25, 2022 7:53 AM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: ???(Youngchul Park) ????? ?????? <youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ?????? <kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ?????? <sehyun2.kim@doosan.com>; ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>Thank you for contacting us regarding our question.
>
>We are interesting about Xenomai Cobalt.
>But, We are not used to apply Xenomai Cobalt.
>So, We have studied about Xenomai Cobalt.
>
>
>Could you explain our questions about Xenomai Cobalt as like below?
>
>If you reply to us our questions, It's very helpful to understand about Xenomai Cobalt.
>
>
>Our issue about Xenomai 3.0.8 ( Linux kernel 4.1.18, ipipe-core-4.1.18-x86-9.patch )
>
>Normal : Xenomai 2.6.5 ( Linux kernel 3.14.44, ipipe-core-3.14.44-x86-12.patch )
>
>
>While ( 1 )
>{
>        A function ();
>        -> A function is printed every 20us by using rt_printf function
>        rt_task_yield () ;
>}
>
>
>Issue : Xenomai 3.0.8 ( Linux kernel 4.1.18, ipipe-core-4.1.18-x86-9.patch )
>
>While ( 1 )
>{
>        A function ();
>        -> A function is printed every 4ms by using rt_printf function.
>        rt_task_yield () ;
>}
>
>
>1.
>What is Xenomai Cobalt Kernel as like ipipe patch ?
>
>If the system call is occurred by the rt_task_yield function in the user space,
>Is Xenomai Cobalt Kernel to schedule a Task without Linux kernel scheduler ?
>If not, Is Xenomai Cobalt Kernel to schedule a Task with Linux kernel scheduler ?
>
>I'm confused the action of  Xenomai Cobalt Kernel.
>Is Xenomai Cobalt Kernel a new Task Scheduler ?
>If not, Do Xenomai Cobalt Kernel use Linux kernel scheduler ?

Cobalt core + Linux kernel core = dual core. Cobalt kernel  run in primary mode and has
It own scheduler and has higher priority than Linux kernel which run in secondary mode.

>
>If we use rt_task_yield function in the user space or sched_yield function in the user space,
>Which is the difference kernel space's action after system call ?

When you run in Realtime domain, rt_task_yield will trap into cobalt core through cobalt ABI different from Linux common ABI.

>
>
>2.
>As I know, Ftrace is used to debug about linux kernel scheduler.
>Do the Xenomai Cobalt kernel to use Ftrace for debugging ?

Yes.  You can find all events related to cobalt from /sys/kernel/debug/tracing/events/cobalt_*


>
>
>3.
>Could you share to us the function in the kernel space after system call if we use rt_task_yield in the user space ?

If you run in primary mode, it may call COBALT_SYSCALL(sched_yield, primary, (void)) in Sched.c (kernel\cobalt\posix) of cobalt,
you can trace cobalt_pthread_yield event if you enable it.

Regards

Hongzhan Chen
>
>
>For example,
>Is the the function in the kernel space difference if we use __RT ( rt_task_yield ) in the user space or _STD ( native task_yield ) in the user space ?


>
>
>#define COBALT_DECL(T, P)       \
>        __typeof__(T) __RT(P);  \
>        __typeof__(T) __STD(P);/
>        __typeof__(T) __WRAP(P)
>
>
>Thanks.
>
>-----Original Message-----
>From: ???(Sehyun Kim) ??? ?????? <sehyun2.kim@doosan.com>
>Sent: Wednesday, August 24, 2022 6:14 PM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>
>If rt_task_yield() works normally, what is the delay time?
>
>
>
>
>
>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>Sent: Tuesday, August 23, 2022 9:51 AM
>To: ???(Sehyun Kim) ??? ?????? <sehyun2.kim@doosan.com>; xenomai@xenomai.org
>Cc: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>>-----Original Message-----
>>From: ???(Sehyun Kim) ??? ?????? mailto:sehyun2.kim@doosan.com
>>Sent: Tuesday, August 23, 2022 8:11 AM
>>To: mailto:xenomai@xenomai.org
>>Cc: ???(Dongjoo Kim) ????? ?????? mailto:dongjoo5.kim@doosan.com
>>Subject: What causes the latency of the rt_task_yield() API?
>>
>>
>>Currently, I am using xenomai 2.6.5 version and am working on changing it to 3.0.8 version.
>>
>>When using version 3.0.8, there is a delay of about 4ms when using
>>rt_task_yield()
>>
>>After creating and starting multiple tasks, rt_task_yield() is still running on all tasks.
>>
>>This is a problem that did not occur in the 2.6.5 version.
>>
>>Is there anything I need to set in version 3.0.8?
>>If not, is it a kernel version issue? (The current kernel version is
>>4.1.18.) If not, is there an API that can replace rt_task_yield() ?
>
>I suggest you may make use of  ftrace  and enable enough events for example sched events to check what the difference happen between these two cases in cobalt core and help narrow down the issue.  I do not know what code difference may cause such issue.
>
>Regards
>
>Hongzhan Chen
>>
>>
>>- previous version
>>
>>Xubuntu : Xubuntu-17.10.1
>>
>>Linux kernel : Linux-3.14.44
>>
>>Xenomai : Xenomai-2.6.5
>>
>>Xenomai Ipipe : ipipe-core-3.14.44-x86-12.patch
>>
>>
>>
>>- current version
>>
>>Xubuntu : Xubuntu 18.04 LTS
>>
>>Linux kernel : Linux kernel 4.1.18
>>
>>Xenomai : Xenomai-3.0.8
>>
>>Xenomai Ipipe : ipipe-core-4.1.18-x86-7.patch
>>
>>
>>Look forward to hearing from you.
>>Best regards.
>>
>>
>>
>>
>>
>>
>>SE HYUN KIM
>>Researcher, R&D Center Control Framework Team
>>
>>Email : mailto:sehyun2.kim@doosan.com
>>Web :
>>http://secure-web.cisco.com/1cJso98gz_hnGZGMPEAQN0liSZnDURNopv4Z1EnCyAy
>>ZNMAK72pG7n_2ENIEMBQt86ogrjZD4WrvNDMYzlo_tkhG-7S6Wr-aSk-7AdOM_TvC8tEDwf
>>zhrndK_My0d8lzyBzH3V2OlLEsmGfoql3Mgt0BV7NxZ6VofyHVVYk5H8Bh5HyavaD0nBABq
>>7VSK0bimlA2BYnpaLCjuJABCtq_rg0djwVf8nfOLP7nirwDevPHOSSHjyP3EMNqoXWgnyuz
>>0k9aaMh_yRqMhu0ERTgy8Ipn9S1v4wjLm80EHV4oUHh9EIQi_Ez79fvAD1Fu7nd62/http%
>>3A%2F%2Fwww.doosanrobotics.com
>
>
>This e-mail and any attachments herein may contain confidential or privileged information and is for the exclusive use of the intended recipient(s) named above. If you are not the intended recipient(s), you should not disseminate, distribute, retain, copy or otherwise use any information contained herein. If you have received this e-mail in error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments. Our company does not guarantee this e-mail is secure or free from viruses.
>? ??? ? ????? ??? ??? ????? ? ??? ???? ?? ??? ?????? ??? ???? ??????? ??? ???? ???? ??? ??, ??, ??? ?? ?? ???? ?? ??? ? ???, ? ??? ??? ???? ???? ??? ??? ??? ??? ??? ??? ?? ???? ?? ????. ?? ???? ???? ?? ????? ???? ???? ? ???? ??? ????. ??? ?? ????.

RE: What causes the latency of the rt_task_yield() API?

[김동주(Dongjoo Kim) 책임연구원 두산로보틱스]

Dear Xenomai.org, Chen, Hongzhan

I'm dong joo.

Thank you for your reply to us our questions.
And, We have checked the Ftrace log.

We have lack of knowledge about Xenomai Cobalt.
So, How do you think about our test result 4ms delay using by Xenomai Cobalt?
Is this result normal or abnormal ?


Our issue about Xenomai 3.0.8 ( Linux kernel 4.1.18,
ipipe-core-4.1.18-x86-9.patch )

Normal : Xenomai 2.6.5 ( Linux kernel 3.14.44,
ipipe-core-3.14.44-x86-12.patch )


While ( 1 )
{
        A function ();
        -> A function is printed every 20us by using rt_printf function
        rt_task_yield () ;
}


Issue : Xenomai 3.0.8 ( Linux kernel 4.1.18,
ipipe-core-4.1.18-x86-9.patch )

While ( 1 )
{
        A function ();
        -> A function is printed every 4ms by using rt_printf function.
        rt_task_yield () ;
}

Thanks

-----Original Message-----
From: Chen, Hongzhan <hongzhan.chen@intel.com>
Sent: Thursday, August 25, 2022 10:07 AM
To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>; xenomai@xenomai.org
Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원 두산로보틱스 <kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스 <sehyun2.kim@doosan.com>
Subject: RE: What causes the latency of the rt_task_yield() API?

주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시 주의하시기 바랍니다.

CAUTION: This email is sent by an external account. Please take extra caution when clicking the link or opening the attachment.

>-----Original Message-----
>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>Sent: Thursday, August 25, 2022 7:53 AM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: ???(Youngchul Park) ????? ?????? <youngchul3.park@doosan.com>;
>???(Kyunghoon Park) ????? ?????? <kyunghoon2.park@doosan.com>;
>???(Sehyun Kim) ??? ?????? <sehyun2.kim@doosan.com>; ???(Dongjoo Kim)
>????? ?????? <dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>Thank you for contacting us regarding our question.
>
>We are interesting about Xenomai Cobalt.
>But, We are not used to apply Xenomai Cobalt.
>So, We have studied about Xenomai Cobalt.
>
>
>Could you explain our questions about Xenomai Cobalt as like below?
>
>If you reply to us our questions, It's very helpful to understand about Xenomai Cobalt.
>
>
>Our issue about Xenomai 3.0.8 ( Linux kernel 4.1.18,
>ipipe-core-4.1.18-x86-9.patch )
>
>Normal : Xenomai 2.6.5 ( Linux kernel 3.14.44,
>ipipe-core-3.14.44-x86-12.patch )
>
>
>While ( 1 )
>{
>        A function ();
>        -> A function is printed every 20us by using rt_printf function
>        rt_task_yield () ;
>}
>
>
>Issue : Xenomai 3.0.8 ( Linux kernel 4.1.18,
>ipipe-core-4.1.18-x86-9.patch )
>
>While ( 1 )
>{
>        A function ();
>        -> A function is printed every 4ms by using rt_printf function.
>        rt_task_yield () ;
>}
>
>
>1.
>What is Xenomai Cobalt Kernel as like ipipe patch ?
>
>If the system call is occurred by the rt_task_yield function in the
>user space, Is Xenomai Cobalt Kernel to schedule a Task without Linux kernel scheduler ?
>If not, Is Xenomai Cobalt Kernel to schedule a Task with Linux kernel scheduler ?
>
>I'm confused the action of  Xenomai Cobalt Kernel.
>Is Xenomai Cobalt Kernel a new Task Scheduler ?
>If not, Do Xenomai Cobalt Kernel use Linux kernel scheduler ?

Cobalt core + Linux kernel core = dual core. Cobalt kernel  run in primary mode and has It own scheduler and has higher priority than Linux kernel which run in secondary mode.

>
>If we use rt_task_yield function in the user space or sched_yield
>function in the user space, Which is the difference kernel space's action after system call ?

When you run in Realtime domain, rt_task_yield will trap into cobalt core through cobalt ABI different from Linux common ABI.

>
>
>2.
>As I know, Ftrace is used to debug about linux kernel scheduler.
>Do the Xenomai Cobalt kernel to use Ftrace for debugging ?

Yes.  You can find all events related to cobalt from /sys/kernel/debug/tracing/events/cobalt_*


>
>
>3.
>Could you share to us the function in the kernel space after system call if we use rt_task_yield in the user space ?

If you run in primary mode, it may call COBALT_SYSCALL(sched_yield, primary, (void)) in Sched.c (kernel\cobalt\posix) of cobalt, you can trace cobalt_pthread_yield event if you enable it.

Regards

Hongzhan Chen
>
>
>For example,
>Is the the function in the kernel space difference if we use __RT ( rt_task_yield ) in the user space or _STD ( native task_yield ) in the user space ?


>
>
>#define COBALT_DECL(T, P)       \
>        __typeof__(T) __RT(P);  \
>        __typeof__(T) __STD(P);/
>        __typeof__(T) __WRAP(P)
>
>
>Thanks.
>
>-----Original Message-----
>From: ???(Sehyun Kim) ??? ?????? <sehyun2.kim@doosan.com>
>Sent: Wednesday, August 24, 2022 6:14 PM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>
>If rt_task_yield() works normally, what is the delay time?
>
>
>
>
>
>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>Sent: Tuesday, August 23, 2022 9:51 AM
>To: ???(Sehyun Kim) ??? ?????? <sehyun2.kim@doosan.com>;
>xenomai@xenomai.org
>Cc: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>>-----Original Message-----
>>From: ???(Sehyun Kim) ??? ?????? mailto:sehyun2.kim@doosan.com
>>Sent: Tuesday, August 23, 2022 8:11 AM
>>To: mailto:xenomai@xenomai.org
>>Cc: ???(Dongjoo Kim) ????? ?????? mailto:dongjoo5.kim@doosan.com
>>Subject: What causes the latency of the rt_task_yield() API?
>>
>>
>>Currently, I am using xenomai 2.6.5 version and am working on changing it to 3.0.8 version.
>>
>>When using version 3.0.8, there is a delay of about 4ms when using
>>rt_task_yield()
>>
>>After creating and starting multiple tasks, rt_task_yield() is still running on all tasks.
>>
>>This is a problem that did not occur in the 2.6.5 version.
>>
>>Is there anything I need to set in version 3.0.8?
>>If not, is it a kernel version issue? (The current kernel version is
>>4.1.18.) If not, is there an API that can replace rt_task_yield() ?
>
>I suggest you may make use of  ftrace  and enable enough events for example sched events to check what the difference happen between these two cases in cobalt core and help narrow down the issue.  I do not know what code difference may cause such issue.
>
>Regards
>
>Hongzhan Chen
>>
>>
>>- previous version
>>
>>Xubuntu : Xubuntu-17.10.1
>>
>>Linux kernel : Linux-3.14.44
>>
>>Xenomai : Xenomai-2.6.5
>>
>>Xenomai Ipipe : ipipe-core-3.14.44-x86-12.patch
>>
>>
>>
>>- current version
>>
>>Xubuntu : Xubuntu 18.04 LTS
>>
>>Linux kernel : Linux kernel 4.1.18
>>
>>Xenomai : Xenomai-3.0.8
>>
>>Xenomai Ipipe : ipipe-core-4.1.18-x86-7.patch
>>
>>
>>Look forward to hearing from you.
>>Best regards.
>>
>>
>>
>>
>>
>>
>>SE HYUN KIM
>>Researcher, R&D Center Control Framework Team
>>
>>Email : mailto:sehyun2.kim@doosan.com
>>Web :
>>http://secure-web.cisco.com/1cJso98gz_hnGZGMPEAQN0liSZnDURNopv4Z1EnCyA
>>y
>>ZNMAK72pG7n_2ENIEMBQt86ogrjZD4WrvNDMYzlo_tkhG-7S6Wr-aSk-7AdOM_TvC8tEDw
>>f
>>zhrndK_My0d8lzyBzH3V2OlLEsmGfoql3Mgt0BV7NxZ6VofyHVVYk5H8Bh5HyavaD0nBAB
>>q
>>7VSK0bimlA2BYnpaLCjuJABCtq_rg0djwVf8nfOLP7nirwDevPHOSSHjyP3EMNqoXWgnyu
>>z
>>0k9aaMh_yRqMhu0ERTgy8Ipn9S1v4wjLm80EHV4oUHh9EIQi_Ez79fvAD1Fu7nd62/http
>>%
>>3A%2F%2Fwww.doosanrobotics.com
>
>
>This e-mail and any attachments herein may contain confidential or privileged information and is for the exclusive use of the intended recipient(s) named above. If you are not the intended recipient(s), you should not disseminate, distribute, retain, copy or otherwise use any information contained herein. If you have received this e-mail in error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments. Our company does not guarantee this e-mail is secure or free from viruses.
>? ??? ? ????? ??? ??? ????? ? ??? ???? ?? ??? ?????? ??? ???? ??????? ??? ???? ???? ??? ??, ??, ??? ?? ?? ???? ?? ??? ? ???, ? ??? ??? ???? ???? ??? ??? ??? ??? ??? ??? ?? ???? ?? ????. ?? ???? ???? ?? ????? ???? ???? ? ???? ??? ????. ??? ?? ????.


This e-mail and any attachments herein may contain confidential or privileged information and is for the exclusive use of the intended recipient(s) named above. If you are not the intended recipient(s), you should not disseminate, distribute, retain, copy or otherwise use any information contained herein. If you have received this e-mail in error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments. Our company does not guarantee this e-mail is secure or free from viruses.
이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[Chen, Hongzhan]

>-----Original Message-----
>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com> 
>Sent: Thursday, August 25, 2022 12:18 PM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: ???(Youngchul Park) ????? ?????? <youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ?????? <kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ?????? <sehyun2.kim@doosan.com>; ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>Thank you for your reply to us our questions.
>And, We have checked the Ftrace log.
>
>We have lack of knowledge about Xenomai Cobalt.
>So, How do you think about our test result 4ms delay using by Xenomai Cobalt?
>Is this result normal or abnormal ?

If there is no other RT thread occupying CPU, the delay should not be larger than TICK_NSEC. TICK_NSEC depends on your system.

Regards

Hongzhan Chen

>
>
>Our issue about Xenomai 3.0.8 ( Linux kernel 4.1.18,
>ipipe-core-4.1.18-x86-9.patch )
>
>Normal : Xenomai 2.6.5 ( Linux kernel 3.14.44,
>ipipe-core-3.14.44-x86-12.patch )
>
>
>While ( 1 )
>{
>        A function ();
>        -> A function is printed every 20us by using rt_printf function
>        rt_task_yield () ;
>}
>
>
>Issue : Xenomai 3.0.8 ( Linux kernel 4.1.18,
>ipipe-core-4.1.18-x86-9.patch )
>
>While ( 1 )
>{
>        A function ();
>        -> A function is printed every 4ms by using rt_printf function.
>        rt_task_yield () ;
>}
>
>Thanks
>
>-----Original Message-----
>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>Sent: Thursday, August 25, 2022 10:07 AM
>To: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>Cc: ???(Youngchul Park) ????? ?????? <youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ?????? <kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ?????? <sehyun2.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?

RE: What causes the latency of the rt_task_yield() API?

[김동주(Dongjoo Kim) 책임연구원 두산로보틱스]

Dear Xenomai.org, Chen, Hongzhan

I'm dong joo.

Thank you for your reply to us our questions.

And, We have checked the value of TICK_NSEC int our system.

#define TICK_NSEC ((NSEC_PER_SEC+HZ/2)/HZ)
#define NSEC_PER_SEC   1000000000L
HZ  250 ( Max 1000 )

The value of TICK_NSEC is defined by linux kernel.
And, Both NSEC_PER_SEC and HZ calculate the value of TICK_NSEC.

So, The current value of TICK_NSEC is 4ms based on 250 HZ.
And, If we change the value of HZ to 1000, The value of TICK_NSEC may be 1ms.


We hope to process a task every 20us using rt_task_yield as like Xenomai 2.6.5.

Is there any method to achieve 20us task delay using rt_task_yield or another xenomai method ?
And, Is there any problem to reduce the delay more less than TICK_NSEC ?


Really Thanks.

-----Original Message-----
From: Chen, Hongzhan <hongzhan.chen@intel.com>
Sent: Thursday, August 25, 2022 3:20 PM
To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>; xenomai@xenomai.org
Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원 두산로보틱스 <kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스 <sehyun2.kim@doosan.com>
Subject: RE: What causes the latency of the rt_task_yield() API?

주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시 주의하시기 바랍니다.

CAUTION: This email is sent by an external account. Please take extra caution when clicking the link or opening the attachment.

>-----Original Message-----
>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>Sent: Thursday, August 25, 2022 12:18 PM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: ???(Youngchul Park) ????? ?????? <youngchul3.park@doosan.com>;
>???(Kyunghoon Park) ????? ?????? <kyunghoon2.park@doosan.com>;
>???(Sehyun Kim) ??? ?????? <sehyun2.kim@doosan.com>; ???(Dongjoo Kim)
>????? ?????? <dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>Thank you for your reply to us our questions.
>And, We have checked the Ftrace log.
>
>We have lack of knowledge about Xenomai Cobalt.
>So, How do you think about our test result 4ms delay using by Xenomai Cobalt?
>Is this result normal or abnormal ?

If there is no other RT thread occupying CPU, the delay should not be larger than TICK_NSEC. TICK_NSEC depends on your system.

Regards

Hongzhan Chen

>
>
>Our issue about Xenomai 3.0.8 ( Linux kernel 4.1.18,
>ipipe-core-4.1.18-x86-9.patch )
>
>Normal : Xenomai 2.6.5 ( Linux kernel 3.14.44,
>ipipe-core-3.14.44-x86-12.patch )
>
>
>While ( 1 )
>{
>        A function ();
>        -> A function is printed every 20us by using rt_printf function
>        rt_task_yield () ;
>}
>
>
>Issue : Xenomai 3.0.8 ( Linux kernel 4.1.18,
>ipipe-core-4.1.18-x86-9.patch )
>
>While ( 1 )
>{
>        A function ();
>        -> A function is printed every 4ms by using rt_printf function.
>        rt_task_yield () ;
>}
>
>Thanks
>
>-----Original Message-----
>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>Sent: Thursday, August 25, 2022 10:07 AM
>To: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>;
>xenomai@xenomai.org
>Cc: ???(Youngchul Park) ????? ?????? <youngchul3.park@doosan.com>;
>???(Kyunghoon Park) ????? ?????? <kyunghoon2.park@doosan.com>;
>???(Sehyun Kim) ??? ?????? <sehyun2.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?


This e-mail and any attachments herein may contain confidential or privileged information and is for the exclusive use of the intended recipient(s) named above. If you are not the intended recipient(s), you should not disseminate, distribute, retain, copy or otherwise use any information contained herein. If you have received this e-mail in error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments. Our company does not guarantee this e-mail is secure or free from viruses.
이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[Chen, Hongzhan]

>-----Original Message-----
>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com> 
>Sent: Friday, August 26, 2022 10:41 AM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: ???(Youngchul Park) ????? ?????? <youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ?????? <kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ?????? <sehyun2.kim@doosan.com>; ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>Thank you for your reply to us our questions.
>
>And, We have checked the value of TICK_NSEC int our system.
>
>#define TICK_NSEC ((NSEC_PER_SEC+HZ/2)/HZ)
>#define NSEC_PER_SEC   1000000000L
>HZ  250 ( Max 1000 )
>
>The value of TICK_NSEC is defined by linux kernel.
>And, Both NSEC_PER_SEC and HZ calculate the value of TICK_NSEC.
>
>So, The current value of TICK_NSEC is 4ms based on 250 HZ.
>And, If we change the value of HZ to 1000, The value of TICK_NSEC may be 1ms.
>
>
>We hope to process a task every 20us using rt_task_yield as like Xenomai 2.6.5.
>
>Is there any method to achieve 20us task delay using rt_task_yield or another xenomai method ?
>And, Is there any problem to reduce the delay more less than TICK_NSEC ?

I just went through the implementation of rt_task_yield of Xeomai 2.6.5 and found that it is totally different from Xenomai 3.0.8.
If you want to yield about 20us for current RT thread ,you may try call clock_nanosleep .
.
Regards

Hongzhan Chen
>
>
>Really Thanks.
>

RE: What causes the latency of the rt_task_yield() API?

[김동주(Dongjoo Kim) 책임연구원 두산로보틱스]

Dear Xenomai.org, Chen, Hongzhan

I'm dong joo.

Thank you for your reply to us our questions.

We have a questions about Xenomai build.

We install Ubuntu 20.04.5 LTS our linux build server.
The Ubuntu 20.04.5 LTS is 64bit( X86_64 ).

And, We also install gcc-4.8 compiler based on 64bit.

We want to build about Xenomai build for X86( 32bit) Target.
So, We use the script based on Xenomai document.


But, configure happen to fail.
Is there any method to success Xenomai configure?


https://xenomai.org/documentation/xenomai-3/pdf/README.INSTALL.pdf

$ mkdir $build_root && cd $build_root
$ $xenomai_root/configure --with-core=cobalt --enable-smp --enable-pshared \
--host=i686-linux CFLAGS="-m32 -O2" LDFLAGS="-m32"
$ make install


user@develop:/home/dongjoo5.kim/temp/xenomai-3.0.8$ sudo ./configure --with-core=cobalt --enable-smp --enable-pshared --host=i686-linux CFLAGS="-m32 -O2" LDFLAGS="-m32"
checking whether we build for Cobalt or Mercury core... cobalt
checking build system type... x86_64-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking for i686-linux-gcc... no
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/home/dongjoo5.kim/temp/xenomai-3.0.8':
configure: error: C compiler cannot create executables
See `config.log' for more details



config.log

configure:3017: $? = 0
configure:3006: gcc -v >&5
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.5-4ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.5 (Ubuntu 4.8.5-4ubuntu2)
configure:3017: $? = 0
configure:3006: gcc -V >&5
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:3017: $? = 4
configure:3006: gcc -qversion >&5
gcc: error: unrecognized command line option '-qversion'
gcc: fatal error: no input files
compilation terminated.
configure:3017: $? = 4

Thanks.

-----Original Message-----
From: Chen, Hongzhan <hongzhan.chen@intel.com>
Sent: Friday, August 26, 2022 2:40 PM
To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>; xenomai@xenomai.org
Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원 두산로보틱스 <kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스 <sehyun2.kim@doosan.com>
Subject: RE: What causes the latency of the rt_task_yield() API?

주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시 주의하시기 바랍니다.

CAUTION: This email is sent by an external account. Please take extra caution when clicking the link or opening the attachment.

>-----Original Message-----
>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>Sent: Friday, August 26, 2022 10:41 AM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: ???(Youngchul Park) ????? ?????? <youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ?????? <kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ?????? <sehyun2.kim@doosan.com>; ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>Thank you for your reply to us our questions.
>
>And, We have checked the value of TICK_NSEC int our system.
>
>#define TICK_NSEC ((NSEC_PER_SEC+HZ/2)/HZ)
>#define NSEC_PER_SEC   1000000000L
>HZ  250 ( Max 1000 )
>
>The value of TICK_NSEC is defined by linux kernel.
>And, Both NSEC_PER_SEC and HZ calculate the value of TICK_NSEC.
>
>So, The current value of TICK_NSEC is 4ms based on 250 HZ.
>And, If we change the value of HZ to 1000, The value of TICK_NSEC may be 1ms.
>
>
>We hope to process a task every 20us using rt_task_yield as like Xenomai 2.6.5.
>
>Is there any method to achieve 20us task delay using rt_task_yield or another xenomai method ?
>And, Is there any problem to reduce the delay more less than TICK_NSEC ?

I just went through the implementation of rt_task_yield of Xeomai 2.6.5 and found that it is totally different from Xenomai 3.0.8.
If you want to yield about 20us for current RT thread ,you may try call clock_nanosleep .
.
Regards

Hongzhan Chen
>
>
>Really Thanks.
>


This e-mail and any attachments herein may contain confidential or privileged information and is for the exclusive use of the intended recipient(s) named above. If you are not the intended recipient(s), you should not disseminate, distribute, retain, copy or otherwise use any information contained herein. If you have received this e-mail in error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments. Our company does not guarantee this e-mail is secure or free from viruses.
이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[Chen, Hongzhan]

>-----Original Message-----
>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com> 
>Sent: Thursday, September 1, 2022 3:00 PM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: ???(Youngchul Park) ????? ?????? <youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ?????? <kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ?????? <sehyun2.kim@doosan.com>; ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>; ???(Sangjin Kim) ????? ?????? <sangjin5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>Thank you for your reply to us our questions.
>
>We have a questions about Xenomai build.
>
>We install Ubuntu 20.04.5 LTS our linux build server.
>The Ubuntu 20.04.5 LTS is 64bit( X86_64 ).
>
>And, We also install gcc-4.8 compiler based on 64bit.
>
>We want to build about Xenomai build for X86( 32bit) Target.
>So, We use the script based on Xenomai document.
>
>
>But, configure happen to fail.
>Is there any method to success Xenomai configure?
>
>
>https://xenomai.org/documentation/xenomai-3/pdf/README.INSTALL.pdf
>
>$ mkdir $build_root && cd $build_root
>$ $xenomai_root/configure --with-core=cobalt --enable-smp --enable-pshared \
>--host=i686-linux CFLAGS="-m32 -O2" LDFLAGS="-m32"
>$ make install
>
>
>user@develop:/home/dongjoo5.kim/temp/xenomai-3.0.8$ sudo ./configure --with-core=cobalt --enable-smp --enable-pshared --host=i686-linux CFLAGS="-m32 -O2" LDFLAGS="-m32"
>checking whether we build for Cobalt or Mercury core... cobalt
>checking build system type... x86_64-pc-linux-gnu
>checking host system type... i686-pc-linux-gnu
>checking for a BSD-compatible install... /usr/bin/install -c
>checking for i686-linux-gcc... no
 checking for gcc... gcc
>checking whether the C compiler works... no
>configure: error: in `/home/dongjoo5.kim/temp/xenomai-3.0.8':
>configure: error: C compiler cannot create executables
>See `config.log' for more details
>
>
>
>config.log
>
>configure:3017: $? = 0
>configure:3006: gcc -v >&5
>Using built-in specs.
>COLLECT_GCC=gcc
>COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
>Target: x86_64-linux-gnu
>Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.5-4ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
>Thread model: posix
>gcc version 4.8.5 (Ubuntu 4.8.5-4ubuntu2)
>configure:3017: $? = 0
>configure:3006: gcc -V >&5
>gcc: error: unrecognized command line option '-V'
>gcc: fatal error: no input files
>compilation terminated.
>configure:3017: $? = 4
>configure:3006: gcc -qversion >&5
>gcc: error: unrecognized command line option '-qversion'
>gcc: fatal error: no input files
>compilation terminated.
>configure:3017: $? = 4
>
>Thanks.

It is common autoconfig issue. You may try methods mentioned in [1] for example install necessary package via running  sudo apt-get install build-essential.

[1]: https://stackoverflow.com/questions/20678016/autoconf-complains-c-compiler-cannot-create-executables-on-linux-mint

Regards

Hongzhan Chen

RE: What causes the latency of the rt_task_yield() API?

[김동주(Dongjoo Kim) 책임연구원 두산로보틱스]

Dear Xenomai.org, Chen, Hongzhan

I'm dong joo.

After installing build-essential, Xenomai configure error also happen.
Could you help me to solve a Xenomai configure error ?

If We install gcc-4.8 compiler based on 32bit, Xenomai configure error don't happen.

1. We install gcc-4.8 compiler based on 64bit.

2. We want to build about Xenomai build for X86( 32bit) Target.
   So, We use the script based on Xenomai document.

3. configure happen to fail.

Thanks.


-----Original Message-----
From: Chen, Hongzhan <hongzhan.chen@intel.com>
Sent: Thursday, September 1, 2022 4:49 PM
To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>; xenomai@xenomai.org
Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원 두산로보틱스 <kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스 <sehyun2.kim@doosan.com>; 김상진(Sangjin Kim) 주임연구원 두산로보틱스 <sangjin5.kim@doosan.com>
Subject: RE: What causes the latency of the rt_task_yield() API?

주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시 주의하시기 바랍니다.

CAUTION: This email is sent by an external account. Please take extra caution when clicking the link or opening the attachment.

>-----Original Message-----
>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>Sent: Thursday, September 1, 2022 3:00 PM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: ???(Youngchul Park) ????? ?????? <youngchul3.park@doosan.com>;
>???(Kyunghoon Park) ????? ?????? <kyunghoon2.park@doosan.com>;
>???(Sehyun Kim) ??? ?????? <sehyun2.kim@doosan.com>; ???(Dongjoo Kim)
>????? ?????? <dongjoo5.kim@doosan.com>; ???(Sangjin Kim) ????? ??????
><sangjin5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>Thank you for your reply to us our questions.
>
>We have a questions about Xenomai build.
>
>We install Ubuntu 20.04.5 LTS our linux build server.
>The Ubuntu 20.04.5 LTS is 64bit( X86_64 ).
>
>And, We also install gcc-4.8 compiler based on 64bit.
>
>We want to build about Xenomai build for X86( 32bit) Target.
>So, We use the script based on Xenomai document.
>
>
>But, configure happen to fail.
>Is there any method to success Xenomai configure?
>
>
>https://secure-web.cisco.com/1WzmZydd4WJf5mm01snhqyS9H7vts9jHzKb4RvMevL
>uGVLuQclf-xtdzn0s9vmAg0O_B0TMZZZxxywMT9lM8Trhdi5IZQRizyuV03U3mGlY7aYvh1
>APe2VF1pCYNPJtAIH0XMxAt9D00zJVQ_Z1Pdh3GeCH-4T-Ab8whzUKZHU_8qUOiXYSZoxYn
>acGQftMGkz04hnou53BsnjfDKQV8wrSa46ri1JSE-AY4Yi330znPKrXnJPgaF_A9ZKat1hC
>k0FsCyvuqyGouEcf4DB_jVHGpV5zQZaD_04RZp6l3eQvErN3B8ODaGmD1u_F9a-NnK/http
>s%3A%2F%2Fxenomai.org%2Fdocumentation%2Fxenomai-3%2Fpdf%2FREADME.INSTAL
>L.pdf
>
>$ mkdir $build_root && cd $build_root
>$ $xenomai_root/configure --with-core=cobalt --enable-smp
>--enable-pshared \ --host=i686-linux CFLAGS="-m32 -O2" LDFLAGS="-m32"
>$ make install
>
>
>user@develop:/home/dongjoo5.kim/temp/xenomai-3.0.8$ sudo ./configure --with-core=cobalt --enable-smp --enable-pshared --host=i686-linux CFLAGS="-m32 -O2" LDFLAGS="-m32"
>checking whether we build for Cobalt or Mercury core... cobalt checking
>build system type... x86_64-pc-linux-gnu checking host system type...
>i686-pc-linux-gnu checking for a BSD-compatible install...
>/usr/bin/install -c checking for i686-linux-gcc... no
 checking for gcc... gcc
>checking whether the C compiler works... no
>configure: error: in `/home/dongjoo5.kim/temp/xenomai-3.0.8':
>configure: error: C compiler cannot create executables See `config.log'
>for more details
>
>
>
>config.log
>
>configure:3017: $? = 0
>configure:3006: gcc -v >&5
>Using built-in specs.
>COLLECT_GCC=gcc
>COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
>Target: x86_64-linux-gnu
>Configured with: ../src/configure -v --with-pkgversion='Ubuntu
>4.8.5-4ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
>--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
>--program-suffix=-4.8 --enable-shared --enable-linker-build-id
>--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
>--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib
>--enable-nls --with-sysroot=/ --enable-clocale=gnu
>--enable-libstdcxx-debug --enable-libstdcxx-time=yes
>--enable-gnu-unique-object --disable-libmudflap --enable-plugin
>--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
>--enable-gtk-cairo
>--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
>--enable-java-home
>--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
>--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
>--with-arch-directory=amd64
>--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc
>--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
>--with-multilib-list=m32,m64,mx32 --with-tune=generic
>--enable-checking=release --build=x86_64-linux-gnu
>--host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix
>gcc version 4.8.5 (Ubuntu 4.8.5-4ubuntu2)
>configure:3017: $? = 0
>configure:3006: gcc -V >&5
>gcc: error: unrecognized command line option '-V'
>gcc: fatal error: no input files
>compilation terminated.
>configure:3017: $? = 4
>configure:3006: gcc -qversion >&5
>gcc: error: unrecognized command line option '-qversion'
>gcc: fatal error: no input files
>compilation terminated.
>configure:3017: $? = 4
>
>Thanks.

It is common autoconfig issue. You may try methods mentioned in [1] for example install necessary package via running  sudo apt-get install build-essential.

[1]: https://secure-web.cisco.com/16Gmw-6r1lgX_KYFPhrEyjegYdR0fliQVqQ9Y14mX-xN9EA1BlE7l6QeCbUo2L7zZii9EiqYQoaNgbPGvola9Vs0gqnePg2_jbZVlw4qR1UNx2iGAYE2dM7Ij36tpmUYjcbsrV8K46fZgW0bovDb64K7LWMAOne8WSg1zbTwe3C0Y1MhX9MB2wt2wyhP9qsOeOZjaxHzvqAoV8PeU82ZN2uWtq5d87VWji8M1c44UXufqIwhp_dbG7Fxk6gP9f0JspK-0jbNbZmm4f4b40IddmSFGy0GK3mh-of3rMKjB97-R_yPzVzwQWMwXkPGrlHq1/https%3A%2F%2Fstackoverflow.com%2Fquestions%2F20678016%2Fautoconf-complains-c-compiler-cannot-create-executables-on-linux-mint

Regards

Hongzhan Chen



This e-mail and any attachments herein may contain confidential or privileged information and is for the exclusive use of the intended recipient(s) named above. If you are not the intended recipient(s), you should not disseminate, distribute, retain, copy or otherwise use any information contained herein. If you have received this e-mail in error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments. Our company does not guarantee this e-mail is secure or free from viruses.
이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[Chen, Hongzhan]

>-----Original Message-----
>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com> 
>Sent: Monday, September 5, 2022 9:24 AM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: ???(Youngchul Park) ????? ?????? <youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ?????? <kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ?????? <sehyun2.kim@doosan.com>; ???(Sangjin Kim) ????? ?????? <sangjin5.kim@doosan.com>; ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>After installing build-essential, Xenomai configure error also happen.
>Could you help me to solve a Xenomai configure error ?
>
>If We install gcc-4.8 compiler based on 32bit, Xenomai configure error don't happen.
>
>1. We install gcc-4.8 compiler based on 64bit.

To compile gcc 4.8 32-bit program:

Please make sure all the 32-bit gcc 4.8 development tools are completely installed for your case:

sudo apt-get install lib32gcc-4.8-dev


Regards

Hongzhan Chen

>
>2. We want to build about Xenomai build for X86( 32bit) Target.
>   So, We use the script based on Xenomai document.
>
>3. configure happen to fail.
>
>Thanks.
>
>

RE: What causes the latency of the rt_task_yield() API?

[김동주(Dongjoo Kim) 책임연구원 두산로보틱스]

Dear Xenomai.org, Chen, Hongzhan

I'm dong joo.

Thanks for your response about our questions.

We have checked the kernel configuration using Xenomai.
And, Most guide recommend to disable Power management options.

Is there any reason to disable Power management options ?

If the guide is right, We'll disable Power management options.

https://rtt-lwr.readthedocs.io/en/latest/rtpc/xenomai3.html

Power management and ACPI options
  --> CPU Frequency scaling
      --> CPU Frequency scaling (Disable)
  --> ACPI (Advanced Configuration and Power Interface) Support
      --> Processor (Disable)
  --> CPU Idle
      --> CPU idle PM support (Disable)


Thanks.

-----Original Message-----
From: Chen, Hongzhan <hongzhan.chen@intel.com>
Sent: Monday, September 5, 2022 11:47 AM
To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>; xenomai@xenomai.org
Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원 두산로보틱스 <kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스 <sehyun2.kim@doosan.com>; 김상진(Sangjin Kim) 주임연구원 두산로보틱스 <sangjin5.kim@doosan.com>
Subject: RE: What causes the latency of the rt_task_yield() API?

주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시 주의하시기 바랍니다.

CAUTION: This email is sent by an external account. Please take extra caution when clicking the link or opening the attachment.

>-----Original Message-----
>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>Sent: Monday, September 5, 2022 9:24 AM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: ???(Youngchul Park) ????? ?????? <youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ?????? <kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ?????? <sehyun2.kim@doosan.com>; ???(Sangjin Kim) ????? ?????? <sangjin5.kim@doosan.com>; ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>After installing build-essential, Xenomai configure error also happen.
>Could you help me to solve a Xenomai configure error ?
>
>If We install gcc-4.8 compiler based on 32bit, Xenomai configure error don't happen.
>
>1. We install gcc-4.8 compiler based on 64bit.

To compile gcc 4.8 32-bit program:

Please make sure all the 32-bit gcc 4.8 development tools are completely installed for your case:

sudo apt-get install lib32gcc-4.8-dev


Regards

Hongzhan Chen

>
>2. We want to build about Xenomai build for X86( 32bit) Target.
>   So, We use the script based on Xenomai document.
>
>3. configure happen to fail.
>
>Thanks.
>
>


This e-mail and any attachments herein may contain confidential or privileged information and is for the exclusive use of the intended recipient(s) named above. If you are not the intended recipient(s), you should not disseminate, distribute, retain, copy or otherwise use any information contained herein. If you have received this e-mail in error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments. Our company does not guarantee this e-mail is secure or free from viruses.
이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[Chen, Hongzhan]

>-----Original Message-----
>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Sent: Tuesday, September 6, 2022 9:09 AM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>두산로보틱스 <kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim)
>연구원 두산로보틱스 <sehyun2.kim@doosan.com>; 김상진(Sangjin Kim)
>주임연구원 두산로보틱스 <sangjin5.kim@doosan.com>; 장용혁(Yonghyuk
>Jang) 책임연구원 두산로보틱스 <yonghyuk.jang@doosan.com>;
>김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>Thanks for your response about our questions.
>
>We have checked the kernel configuration using Xenomai.
>And, Most guide recommend to disable Power management options.
>
>Is there any reason to disable Power management options ?

Please refer to https://source.denx.de/Xenomai/xenomai/-/wikis/Configuring_For_X86_Based_Dual_Kernels 
for more config options disabling and explanation.

Regards

Hongzhan Chen
>
>If the guide is right, We'll disable Power management options.
>
>https://rtt-lwr.readthedocs.io/en/latest/rtpc/xenomai3.html
>
>Power management and ACPI options
>  --> CPU Frequency scaling
>      --> CPU Frequency scaling (Disable)
>  --> ACPI (Advanced Configuration and Power Interface) Support
>      --> Processor (Disable)
>  --> CPU Idle
>      --> CPU idle PM support (Disable)
>
>
>Thanks.
>
>-----Original Message-----
>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>Sent: Monday, September 5, 2022 11:47 AM
>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>두산로보틱스 <kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim)
>연구원 두산로보틱스 <sehyun2.kim@doosan.com>; 김상진(Sangjin Kim)
>주임연구원 두산로보틱스 <sangjin5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>주의하시기 바랍니다.
>
>CAUTION: This email is sent by an external account. Please take extra caution
>when clicking the link or opening the attachment.
>
>>-----Original Message-----
>>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>>Sent: Monday, September 5, 2022 9:24 AM
>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>Cc: ???(Youngchul Park) ????? ??????
><youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ??????
><kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ??????
><sehyun2.kim@doosan.com>; ???(Sangjin Kim) ????? ??????
><sangjin5.kim@doosan.com>; ???(Dongjoo Kim) ????? ??????
><dongjoo5.kim@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>Dear Xenomai.org, Chen, Hongzhan
>>
>>I'm dong joo.
>>
>>After installing build-essential, Xenomai configure error also happen.
>>Could you help me to solve a Xenomai configure error ?
>>
>>If We install gcc-4.8 compiler based on 32bit, Xenomai configure error don't
>happen.
>>
>>1. We install gcc-4.8 compiler based on 64bit.
>
>To compile gcc 4.8 32-bit program:
>
>Please make sure all the 32-bit gcc 4.8 development tools are completely
>installed for your case:
>
>sudo apt-get install lib32gcc-4.8-dev
>
>
>Regards
>
>Hongzhan Chen
>
>>
>>2. We want to build about Xenomai build for X86( 32bit) Target.
>>   So, We use the script based on Xenomai document.
>>
>>3. configure happen to fail.
>>
>>Thanks.
>>
>>
>
>
>This e-mail and any attachments herein may contain confidential or privileged
>information and is for the exclusive use of the intended recipient(s) named
>above. If you are not the intended recipient(s), you should not disseminate,
>distribute, retain, copy or otherwise use any information contained herein. If
>you have received this e-mail in error, please notify the sender immediately by
>replying to this message and delete this e-mail and associated attachments.
>Our company does not guarantee this e-mail is secure or free from viruses.
>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한
>수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를
>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에
>관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신
>경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기
>바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[김동주(Dongjoo Kim) 책임연구원 두산로보틱스]

Dear Xenomai.org, Chen, Hongzhan

I'm dong joo.

I'm really thanks for your response about our questions.

If we change a function from rt_task_yield method to clock_nanosleep method what you recommend,
Could you share to us the guide how to call clock_nanosleep method ?

We have checked the guide how to set arguments of clock_nanosleep method.
But, There is a few example using clock_nanosleep.


Thanks.

-----Original Message-----
From: Chen, Hongzhan <hongzhan.chen@intel.com>
Sent: Tuesday, September 6, 2022 10:54 AM
To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>; xenomai@xenomai.org
Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원 두산로보틱스 <kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스 <sehyun2.kim@doosan.com>; 김상진(Sangjin Kim) 주임연구원 두산로보틱스 <sangjin5.kim@doosan.com>; 장용혁(Yonghyuk Jang) 책임연구원 두산로보틱스 <yonghyuk.jang@doosan.com>
Subject: RE: What causes the latency of the rt_task_yield() API?

주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시 주의하시기 바랍니다.

CAUTION: This email is sent by an external account. Please take extra caution when clicking the link or opening the attachment.

>-----Original Message-----
>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Sent: Tuesday, September 6, 2022 9:09 AM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원 두산로보틱스
><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 김상진(Sangjin Kim) 주임연구원 두산로보틱스
><sangjin5.kim@doosan.com>; 장용혁(Yonghyuk
>Jang) 책임연구원 두산로보틱스 <yonghyuk.jang@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>두산로보틱스 <dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>Thanks for your response about our questions.
>
>We have checked the kernel configuration using Xenomai.
>And, Most guide recommend to disable Power management options.
>
>Is there any reason to disable Power management options ?

Please refer to https://secure-web.cisco.com/14n1t5FopS0T2tRNNYjRtDV_HRPYwwxklb9PIKWsqCM4GgWGG6Jj-meMInZUohNv7JWqu5EO0hgkJL3gDpLo4Nhcj9wzdm0uZb3RWcM0wj_8_W41t2n-3iATRMgiMkRTUU-anNEW5cVveMJz_-_OaivYORYxB6UkD1fXVJ3kwD1vkRVUlZOb0eXRL15EeyObJpObVZtVIweGS6zsLkX6dtiESAxqOGSw56P2JlK43ICbh1eYP_yt1fGkI24ZBiB0l6F8jtMrbwKJ76kOeee1aJJmEsqs7uylPrNZwBb5h8E4As51Bm0s8l0VB63fgAq3J/https%3A%2F%2Fsource.denx.de%2FXenomai%2Fxenomai%2F-%2Fwikis%2FConfiguring_For_X86_Based_Dual_Kernels
for more config options disabling and explanation.

Regards

Hongzhan Chen
>
>If the guide is right, We'll disable Power management options.
>
>https://secure-web.cisco.com/1wucUNzdaZ5i6LSRN1MFqdSzo8ohTPuXrj4nBYtzjJ
>e4kp3pF0QAw826idpKW4rySYOjpGxrIHqqafFyoo4kH9rfSc6fCs5p4TemhUUu33OWnY7W1
>hz8Ve9zjvsII3pX_GiVEfCCwsFuRq_0W6yP01F6b1El-lB2T8h8A0ci1It8EMxSnrXV6CEN
>NHsAVtraG1P2YIQ5lKN_REvfnd7ddwT7RfzUU7IhSufCozvk-NHiyRU3FdAt1cifgJc-QIt
>TFaglFyOsJD4ou1eZE9Uan5uS3A-YIzutVf3QkgXLKUiPqOR5uBy69nasAALHK_F-4/http
>s%3A%2F%2Frtt-lwr.readthedocs.io%2Fen%2Flatest%2Frtpc%2Fxenomai3.html
>
>Power management and ACPI options
>  --> CPU Frequency scaling
>      --> CPU Frequency scaling (Disable)
>  --> ACPI (Advanced Configuration and Power Interface) Support
>      --> Processor (Disable)
>  --> CPU Idle
>      --> CPU idle PM support (Disable)
>
>
>Thanks.
>
>-----Original Message-----
>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>Sent: Monday, September 5, 2022 11:47 AM
>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원 두산로보틱스
><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 김상진(Sangjin Kim) 주임연구원 두산로보틱스
><sangjin5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시 주의하시기 바랍니다.
>
>CAUTION: This email is sent by an external account. Please take extra
>caution when clicking the link or opening the attachment.
>
>>-----Original Message-----
>>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>>Sent: Monday, September 5, 2022 9:24 AM
>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>Cc: ???(Youngchul Park) ????? ??????
><youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ??????
><kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ??????
><sehyun2.kim@doosan.com>; ???(Sangjin Kim) ????? ??????
><sangjin5.kim@doosan.com>; ???(Dongjoo Kim) ????? ??????
><dongjoo5.kim@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>Dear Xenomai.org, Chen, Hongzhan
>>
>>I'm dong joo.
>>
>>After installing build-essential, Xenomai configure error also happen.
>>Could you help me to solve a Xenomai configure error ?
>>
>>If We install gcc-4.8 compiler based on 32bit, Xenomai configure error
>>don't
>happen.
>>
>>1. We install gcc-4.8 compiler based on 64bit.
>
>To compile gcc 4.8 32-bit program:
>
>Please make sure all the 32-bit gcc 4.8 development tools are
>completely installed for your case:
>
>sudo apt-get install lib32gcc-4.8-dev
>
>
>Regards
>
>Hongzhan Chen
>
>>
>>2. We want to build about Xenomai build for X86( 32bit) Target.
>>   So, We use the script based on Xenomai document.
>>
>>3. configure happen to fail.
>>
>>Thanks.
>>
>>
>
>
>This e-mail and any attachments herein may contain confidential or
>privileged information and is for the exclusive use of the intended
>recipient(s) named above. If you are not the intended recipient(s), you
>should not disseminate, distribute, retain, copy or otherwise use any
>information contained herein. If you have received this e-mail in
>error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments.
>Our company does not guarantee this e-mail is secure or free from viruses.
>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한
>수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.


This e-mail and any attachments herein may contain confidential or privileged information and is for the exclusive use of the intended recipient(s) named above. If you are not the intended recipient(s), you should not disseminate, distribute, retain, copy or otherwise use any information contained herein. If you have received this e-mail in error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments. Our company does not guarantee this e-mail is secure or free from viruses.
이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[Chen, Hongzhan]

>-----Original Message-----
>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Sent: Tuesday, September 6, 2022 2:51 PM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>두산로보틱스 <kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim)
>연구원 두산로보틱스 <sehyun2.kim@doosan.com>; 김상진(Sangjin Kim)
>주임연구원 두산로보틱스 <sangjin5.kim@doosan.com>; 장용혁(Yonghyuk
>Jang) 책임연구원 두산로보틱스 <yonghyuk.jang@doosan.com>;
>김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>I'm really thanks for your response about our questions.
>
>If we change a function from rt_task_yield method to clock_nanosleep
>method what you recommend,
>Could you share to us the guide how to call clock_nanosleep method ?
>
>We have checked the guide how to set arguments of clock_nanosleep method.
>But, There is a few example using clock_nanosleep.

Please refer to line 127-129 of  https://source.denx.de/Xenomai/xenomai/-/blob/master/testsuite/smokey/bufp/bufp.c
It is just one of them. When you search clock_nanosleep under xenomai tree, you can find out lots of cases. 

Regards

Hongzhan Chen
>
>
>Thanks.
>
>-----Original Message-----
>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>Sent: Tuesday, September 6, 2022 10:54 AM
>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>두산로보틱스 <kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim)
>연구원 두산로보틱스 <sehyun2.kim@doosan.com>; 김상진(Sangjin Kim)
>주임연구원 두산로보틱스 <sangjin5.kim@doosan.com>; 장용혁(Yonghyuk
>Jang) 책임연구원 두산로보틱스 <yonghyuk.jang@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>주의하시기 바랍니다.
>
>CAUTION: This email is sent by an external account. Please take extra caution
>when clicking the link or opening the attachment.
>
>>-----Original Message-----
>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>
>>Sent: Tuesday, September 6, 2022 9:09 AM
>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>두산로보틱스
>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>; 김상진(Sangjin Kim) 주임연구원
>두산로보틱스
>><sangjin5.kim@doosan.com>; 장용혁(Yonghyuk
>>Jang) 책임연구원 두산로보틱스 <yonghyuk.jang@doosan.com>;
>김동주(Dongjoo Kim) 책임연구원
>>두산로보틱스 <dongjoo5.kim@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>Dear Xenomai.org, Chen, Hongzhan
>>
>>I'm dong joo.
>>
>>Thanks for your response about our questions.
>>
>>We have checked the kernel configuration using Xenomai.
>>And, Most guide recommend to disable Power management options.
>>
>>Is there any reason to disable Power management options ?
>
>Please refer to https://secure-
>web.cisco.com/14n1t5FopS0T2tRNNYjRtDV_HRPYwwxklb9PIKWsqCM4GgWGG
>6Jj-
>meMInZUohNv7JWqu5EO0hgkJL3gDpLo4Nhcj9wzdm0uZb3RWcM0wj_8_W41t
>2n-3iATRMgiMkRTUU-anNEW5cVveMJz_-
>_OaivYORYxB6UkD1fXVJ3kwD1vkRVUlZOb0eXRL15EeyObJpObVZtVIweGS6zsLk
>X6dtiESAxqOGSw56P2JlK43ICbh1eYP_yt1fGkI24ZBiB0l6F8jtMrbwKJ76kOeee1aJ
>JmEsqs7uylPrNZwBb5h8E4As51Bm0s8l0VB63fgAq3J/https%3A%2F%2Fsource.
>denx.de%2FXenomai%2Fxenomai%2F-
>%2Fwikis%2FConfiguring_For_X86_Based_Dual_Kernels
>for more config options disabling and explanation.
>
>Regards
>
>Hongzhan Chen
>>
>>If the guide is right, We'll disable Power management options.
>>
>>https://secure-
>web.cisco.com/1wucUNzdaZ5i6LSRN1MFqdSzo8ohTPuXrj4nBYtzjJ
>>e4kp3pF0QAw826idpKW4rySYOjpGxrIHqqafFyoo4kH9rfSc6fCs5p4TemhUUu3
>3OWnY7W1
>>hz8Ve9zjvsII3pX_GiVEfCCwsFuRq_0W6yP01F6b1El-
>lB2T8h8A0ci1It8EMxSnrXV6CEN
>>NHsAVtraG1P2YIQ5lKN_REvfnd7ddwT7RfzUU7IhSufCozvk-
>NHiyRU3FdAt1cifgJc-QIt
>>TFaglFyOsJD4ou1eZE9Uan5uS3A-YIzutVf3QkgXLKUiPqOR5uBy69nasAALHK_F-
>4/http
>>s%3A%2F%2Frtt-
>lwr.readthedocs.io%2Fen%2Flatest%2Frtpc%2Fxenomai3.html
>>
>>Power management and ACPI options
>>  --> CPU Frequency scaling
>>      --> CPU Frequency scaling (Disable)
>>  --> ACPI (Advanced Configuration and Power Interface) Support
>>      --> Processor (Disable)
>>  --> CPU Idle
>>      --> CPU idle PM support (Disable)
>>
>>
>>Thanks.
>>
>>-----Original Message-----
>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>Sent: Monday, September 5, 2022 11:47 AM
>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>두산로보틱스
>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>; 김상진(Sangjin Kim) 주임연구원
>두산로보틱스
>><sangjin5.kim@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>주의하시기 바랍니다.
>>
>>CAUTION: This email is sent by an external account. Please take extra
>>caution when clicking the link or opening the attachment.
>>
>>>-----Original Message-----
>>>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>>>Sent: Monday, September 5, 2022 9:24 AM
>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>>Cc: ???(Youngchul Park) ????? ??????
>><youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ??????
>><kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ??????
>><sehyun2.kim@doosan.com>; ???(Sangjin Kim) ????? ??????
>><sangjin5.kim@doosan.com>; ???(Dongjoo Kim) ????? ??????
>><dongjoo5.kim@doosan.com>
>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>
>>>Dear Xenomai.org, Chen, Hongzhan
>>>
>>>I'm dong joo.
>>>
>>>After installing build-essential, Xenomai configure error also happen.
>>>Could you help me to solve a Xenomai configure error ?
>>>
>>>If We install gcc-4.8 compiler based on 32bit, Xenomai configure error
>>>don't
>>happen.
>>>
>>>1. We install gcc-4.8 compiler based on 64bit.
>>
>>To compile gcc 4.8 32-bit program:
>>
>>Please make sure all the 32-bit gcc 4.8 development tools are
>>completely installed for your case:
>>
>>sudo apt-get install lib32gcc-4.8-dev
>>
>>
>>Regards
>>
>>Hongzhan Chen
>>
>>>
>>>2. We want to build about Xenomai build for X86( 32bit) Target.
>>>   So, We use the script based on Xenomai document.
>>>
>>>3. configure happen to fail.
>>>
>>>Thanks.
>>>
>>>
>>
>>
>>This e-mail and any attachments herein may contain confidential or
>>privileged information and is for the exclusive use of the intended
>>recipient(s) named above. If you are not the intended recipient(s), you
>>should not disseminate, distribute, retain, copy or otherwise use any
>>information contained herein. If you have received this e-mail in
>>error, please notify the sender immediately by replying to this message and
>delete this e-mail and associated attachments.
>>Our company does not guarantee this e-mail is secure or free from viruses.
>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한
>>수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를
>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>
>
>This e-mail and any attachments herein may contain confidential or privileged
>information and is for the exclusive use of the intended recipient(s) named
>above. If you are not the intended recipient(s), you should not disseminate,
>distribute, retain, copy or otherwise use any information contained herein. If
>you have received this e-mail in error, please notify the sender immediately by
>replying to this message and delete this e-mail and associated attachments.
>Our company does not guarantee this e-mail is secure or free from viruses.
>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한
>수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를
>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에
>관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신
>경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기
>바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[김동주(Dongjoo Kim) 책임연구원 두산로보틱스]

Dear Xenomai.org, Chen, Hongzhan

I'm dong joo.

After we do a aging test as like latency,
We get a system hang about ten hours later.

At that time, Our system don't detect usb mouse.

After rebooting our system by force,
there is no significative log in the kernel log or syslog.

Could you help to us how to solve this issue ?


We set up our system as like below sw.

1. Xubuntu 18.04 LTS 32bit

2. Linux kernel 4.1.18 32bit

3. Xenomai 3.0.8 32bit

4. Kernel config
   We refer to the xenomai page as like below.

https://source.denx.de/Xenomai/xenomai/-/wikis/Configuring_For_X86_Based_Dual_Kernels#user-content-x86-processor-type

Thanks.

-----Original Message-----
From: Chen, Hongzhan <hongzhan.chen@intel.com>
Sent: Friday, August 26, 2022 2:40 PM
To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>; xenomai@xenomai.org
Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원 두산로보틱스 <kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스 <sehyun2.kim@doosan.com>
Subject: RE: What causes the latency of the rt_task_yield() API?

주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시 주의하시기 바랍니다.

CAUTION: This email is sent by an external account. Please take extra caution when clicking the link or opening the attachment.

>-----Original Message-----
>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>Sent: Friday, August 26, 2022 10:41 AM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: ???(Youngchul Park) ????? ?????? <youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ?????? <kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ?????? <sehyun2.kim@doosan.com>; ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>Thank you for your reply to us our questions.
>
>And, We have checked the value of TICK_NSEC int our system.
>
>#define TICK_NSEC ((NSEC_PER_SEC+HZ/2)/HZ)
>#define NSEC_PER_SEC   1000000000L
>HZ  250 ( Max 1000 )
>
>The value of TICK_NSEC is defined by linux kernel.
>And, Both NSEC_PER_SEC and HZ calculate the value of TICK_NSEC.
>
>So, The current value of TICK_NSEC is 4ms based on 250 HZ.
>And, If we change the value of HZ to 1000, The value of TICK_NSEC may be 1ms.
>
>
>We hope to process a task every 20us using rt_task_yield as like Xenomai 2.6.5.
>
>Is there any method to achieve 20us task delay using rt_task_yield or another xenomai method ?
>And, Is there any problem to reduce the delay more less than TICK_NSEC ?

I just went through the implementation of rt_task_yield of Xeomai 2.6.5 and found that it is totally different from Xenomai 3.0.8.
If you want to yield about 20us for current RT thread ,you may try call clock_nanosleep .
.
Regards

Hongzhan Chen
>
>
>Really Thanks.
>


This e-mail and any attachments herein may contain confidential or privileged information and is for the exclusive use of the intended recipient(s) named above. If you are not the intended recipient(s), you should not disseminate, distribute, retain, copy or otherwise use any information contained herein. If you have received this e-mail in error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments. Our company does not guarantee this e-mail is secure or free from viruses.
이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[Chen, Hongzhan]

>-----Original Message-----
>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Sent: Tuesday, October 25, 2022 3:29 PM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>두산로보틱스 <kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim)
>연구원 두산로보틱스 <sehyun2.kim@doosan.com>; 김동주(Dongjoo Kim)
>책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>; 이재석(Jaesuk Lee)
>상무 두산로보틱스 <jaesuk.lee@doosan.com>; 이영재(Youngjae Lee)
>주임연구원 두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon
>Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>After we do a aging test as like latency,
>We get a system hang about ten hours later.
>
>At that time, Our system don't detect usb mouse.
>
>After rebooting our system by force,
>there is no significative log in the kernel log or syslog.
>
>Could you help to us how to solve this issue ?

Just as mentioned as in https://xenomai.org/pipermail/xenomai/2022-April/047495.html
1. It is highly recommended to use a UART as kernel debug output.
2. enable CONFIG_XENO_OPT_WATCHDOG for xenomai, system will be able to tell
RT application "hangs" (infinite loop at high prio) apart from real hangs/crashes.

Regards

Hongzhan Chen
>
>
>We set up our system as like below sw.
>
>1. Xubuntu 18.04 LTS 32bit
>
>2. Linux kernel 4.1.18 32bit
>
>3. Xenomai 3.0.8 32bit
>
>4. Kernel config
>   We refer to the xenomai page as like below.
>
>https://source.denx.de/Xenomai/xenomai/-
>/wikis/Configuring_For_X86_Based_Dual_Kernels#user-content-x86-
>processor-type
>
>Thanks.
>
>-----Original Message-----
>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>Sent: Friday, August 26, 2022 2:40 PM
>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>두산로보틱스 <kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim)
>연구원 두산로보틱스 <sehyun2.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>주의하시기 바랍니다.
>
>CAUTION: This email is sent by an external account. Please take extra caution
>when clicking the link or opening the attachment.
>
>>-----Original Message-----
>>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>>Sent: Friday, August 26, 2022 10:41 AM
>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>Cc: ???(Youngchul Park) ????? ??????
><youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ??????
><kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ??????
><sehyun2.kim@doosan.com>; ???(Dongjoo Kim) ????? ??????
><dongjoo5.kim@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>Dear Xenomai.org, Chen, Hongzhan
>>
>>I'm dong joo.
>>
>>Thank you for your reply to us our questions.
>>
>>And, We have checked the value of TICK_NSEC int our system.
>>
>>#define TICK_NSEC ((NSEC_PER_SEC+HZ/2)/HZ)
>>#define NSEC_PER_SEC   1000000000L
>>HZ  250 ( Max 1000 )
>>
>>The value of TICK_NSEC is defined by linux kernel.
>>And, Both NSEC_PER_SEC and HZ calculate the value of TICK_NSEC.
>>
>>So, The current value of TICK_NSEC is 4ms based on 250 HZ.
>>And, If we change the value of HZ to 1000, The value of TICK_NSEC may be
>1ms.
>>
>>
>>We hope to process a task every 20us using rt_task_yield as like Xenomai
>2.6.5.
>>
>>Is there any method to achieve 20us task delay using rt_task_yield or another
>xenomai method ?
>>And, Is there any problem to reduce the delay more less than TICK_NSEC ?
>
>I just went through the implementation of rt_task_yield of Xeomai 2.6.5 and
>found that it is totally different from Xenomai 3.0.8.
>If you want to yield about 20us for current RT thread ,you may try call
>clock_nanosleep .
>.
>Regards
>
>Hongzhan Chen
>>
>>
>>Really Thanks.
>>
>
>
>This e-mail and any attachments herein may contain confidential or privileged
>information and is for the exclusive use of the intended recipient(s) named
>above. If you are not the intended recipient(s), you should not disseminate,
>distribute, retain, copy or otherwise use any information contained herein. If
>you have received this e-mail in error, please notify the sender immediately by
>replying to this message and delete this e-mail and associated attachments.
>Our company does not guarantee this e-mail is secure or free from viruses.
>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한
>수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를
>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에
>관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신
>경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기
>바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[김동주(Dongjoo Kim) 책임연구원 두산로보틱스]

Dear Xenomai.org, Chen, Hongzhan

I'm dong joo.

I have a basic question.

If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI Processor CONFIG,
We can't check the current cpu freq by sysnode.

Because, sysnode of cpu freq is related to CPU_FREQ CONFIG and ACPI Processor CONFIG as i know.


If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI Processor CONFIG,
Could you expect the current cpu freq in the intel hw system ?

Actually, The minimum cpu clock of our hw system is very low.

If our hw system operate with minimum cpu clock always,
I worry about the performance of hw system.


sys/devices/system/cpu/cpu0/cpufreq# ls
affected_cpus  cpuinfo_cur_freq  cpuinfo_min_freq            freqdomain_cpus  scaling_available_frequencies  scaling_cur_freq  scaling_governor  scaling_min_freq  stats
bios_limit     cpuinfo_max_freq  cpuinfo_transition_latency  related_cpus     scaling_available_governors    scaling_driver    scaling_max_freq  scaling_setspeed


Thanks.

-----Original Message-----
From: Chen, Hongzhan <hongzhan.chen@intel.com>
Sent: Tuesday, October 25, 2022 5:24 PM
To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>; xenomai@xenomai.org
Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원 두산로보틱스 <kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스 <sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스 <jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>
Subject: RE: What causes the latency of the rt_task_yield() API?

주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시 주의하시기 바랍니다.

CAUTION: This email is sent by an external account. Please take extra caution when clicking the link or opening the attachment.

>-----Original Message-----
>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Sent: Tuesday, October 25, 2022 3:29 PM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원 두산로보틱스
><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스
><youngjae7.lee@doosan.com>; 김상준(Sangjoon
>Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>After we do a aging test as like latency, We get a system hang about
>ten hours later.
>
>At that time, Our system don't detect usb mouse.
>
>After rebooting our system by force,
>there is no significative log in the kernel log or syslog.
>
>Could you help to us how to solve this issue ?

Just as mentioned as in https://secure-web.cisco.com/1ll9UQp4RYnYXuVMxAlJKaDxV1RdMZtBcG3e_jDi4TlIxDMTzFMtJguJhndpS2BnNhGoAWwBP-G2UCWlarucvId1iz_ea_AU-U__8Gq6ZgF285KW8SRPHKr7NeWgE4dKG8o8PGMNJ3-lAB4xdptdPAk1vfJe8AL_Tt6oCEoT0OAr4RrSIjzqtmugt8EHD-jvxghKHjaWu1eGDkzOYtKpcV8WhZnz1wLItIZdChYT1xlXsFTU7-GnJhN2jLvMMlZgkMxzQLejJ2aB1wogBTkBIipva21mNGaSFb_sSZhX9ycwiT7UMUfQg5lyHCPZPEeP6/https%3A%2F%2Fxenomai.org%2Fpipermail%2Fxenomai%2F2022-April%2F047495.html
1. It is highly recommended to use a UART as kernel debug output.
2. enable CONFIG_XENO_OPT_WATCHDOG for xenomai, system will be able to tell RT application "hangs" (infinite loop at high prio) apart from real hangs/crashes.

Regards

Hongzhan Chen
>
>
>We set up our system as like below sw.
>
>1. Xubuntu 18.04 LTS 32bit
>
>2. Linux kernel 4.1.18 32bit
>
>3. Xenomai 3.0.8 32bit
>
>4. Kernel config
>   We refer to the xenomai page as like below.
>
>https://secure-web.cisco.com/1nAW3bSL64gGRUPlQWKtShagcypkiReyVX7nhG1T-J
>upEWaqU-3hnCSt542V_mEwX-_8HsjCaWtSuQnJ3056Yq52DypR5psiqKgrOSq6pbk6xe-tw
>xYZhwwm0akkU4iVwFscbrRTWdk2Ul-9fU2HilSTJ8rzI8X9LIfFg2foor5t9LawggXyjgq3
>QqwJktjRWEhqL8gFDP2PpsmxrTgVK6NzJdcBxzyOGo_jmjjiO009l74YL2U5Ke3A7kc1AX7
>IV_t016CRGEK4QyAKRuSTqKzFm8t4flDV7eBT4m43w-o_SoFrKq-AA7ZIKEYPEgpqq/http
>s%3A%2F%2Fsource.denx.de%2FXenomai%2Fxenomai%2F-
>/wikis/Configuring_For_X86_Based_Dual_Kernels#user-content-x86-
>processor-type
>
>Thanks.
>
>-----Original Message-----
>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>Sent: Friday, August 26, 2022 2:40 PM
>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원 두산로보틱스
><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시 주의하시기 바랍니다.
>
>CAUTION: This email is sent by an external account. Please take extra
>caution when clicking the link or opening the attachment.
>
>>-----Original Message-----
>>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>>Sent: Friday, August 26, 2022 10:41 AM
>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>Cc: ???(Youngchul Park) ????? ??????
><youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ??????
><kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ??????
><sehyun2.kim@doosan.com>; ???(Dongjoo Kim) ????? ??????
><dongjoo5.kim@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>Dear Xenomai.org, Chen, Hongzhan
>>
>>I'm dong joo.
>>
>>Thank you for your reply to us our questions.
>>
>>And, We have checked the value of TICK_NSEC int our system.
>>
>>#define TICK_NSEC ((NSEC_PER_SEC+HZ/2)/HZ)
>>#define NSEC_PER_SEC   1000000000L
>>HZ  250 ( Max 1000 )
>>
>>The value of TICK_NSEC is defined by linux kernel.
>>And, Both NSEC_PER_SEC and HZ calculate the value of TICK_NSEC.
>>
>>So, The current value of TICK_NSEC is 4ms based on 250 HZ.
>>And, If we change the value of HZ to 1000, The value of TICK_NSEC may
>>be
>1ms.
>>
>>
>>We hope to process a task every 20us using rt_task_yield as like
>>Xenomai
>2.6.5.
>>
>>Is there any method to achieve 20us task delay using rt_task_yield or
>>another
>xenomai method ?
>>And, Is there any problem to reduce the delay more less than TICK_NSEC ?
>
>I just went through the implementation of rt_task_yield of Xeomai 2.6.5
>and found that it is totally different from Xenomai 3.0.8.
>If you want to yield about 20us for current RT thread ,you may try call
>clock_nanosleep .
>.
>Regards
>
>Hongzhan Chen
>>
>>
>>Really Thanks.
>>
>
>
>This e-mail and any attachments herein may contain confidential or
>privileged information and is for the exclusive use of the intended
>recipient(s) named above. If you are not the intended recipient(s), you
>should not disseminate, distribute, retain, copy or otherwise use any
>information contained herein. If you have received this e-mail in
>error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments.
>Our company does not guarantee this e-mail is secure or free from viruses.
>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한
>수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.


This e-mail and any attachments herein may contain confidential or privileged information and is for the exclusive use of the intended recipient(s) named above. If you are not the intended recipient(s), you should not disseminate, distribute, retain, copy or otherwise use any information contained herein. If you have received this e-mail in error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments. Our company does not guarantee this e-mail is secure or free from viruses.
이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[김동주(Dongjoo Kim) 책임연구원 두산로보틱스]

Dear Xenomai.org, Chen, Hongzhan

I'm dong joo.

If our rt task using xenomai make a sw hang, how can i debug the reason ?

Is there any method using gdb with core dump ?

After enabling CONFIG_XENO_OPT_WATCHDOG,
Watchdog handler point the hang rt task which is our task using xenomai.


static void watchdog_handler(struct xntimer *timer)
{
        struct xnsched *sched = xnsched_current();
        struct xnthread *curr = sched->curr;

        if (likely(xnthread_test_state(curr, XNROOT))) {
                xnsched_reset_watchdog(sched);
                return;
        }

        if (likely(++sched->wdcount < wd_timeout_arg))
                return;

        trace_cobalt_watchdog_signal(curr);

        if (xnthread_test_state(curr, XNUSER)) {
                printk(XENO_WARNING "watchdog triggered on CPU #%d -- runaway thread "
                       "'%s' signaled\n", xnsched_cpu(sched), curr->name);
                xnthread_call_mayday(curr, SIGDEBUG_WATCHDOG);
        } else {
                printk(XENO_WARNING "watchdog triggered on CPU #%d -- runaway thread "
                       "'%s' canceled\n", xnsched_cpu(sched), curr->name);
                /*
                 * On behalf on an IRQ handler,

Thanks.
-----Original Message-----
From: Chen, Hongzhan <hongzhan.chen@intel.com>
Sent: Tuesday, October 25, 2022 5:24 PM
To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>; xenomai@xenomai.org
Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원 두산로보틱스 <kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스 <sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스 <jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>
Subject: RE: What causes the latency of the rt_task_yield() API?

주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시 주의하시기 바랍니다.

CAUTION: This email is sent by an external account. Please take extra caution when clicking the link or opening the attachment.

>-----Original Message-----
>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Sent: Tuesday, October 25, 2022 3:29 PM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원 두산로보틱스
><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스
><youngjae7.lee@doosan.com>; 김상준(Sangjoon
>Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>After we do a aging test as like latency, We get a system hang about
>ten hours later.
>
>At that time, Our system don't detect usb mouse.
>
>After rebooting our system by force,
>there is no significative log in the kernel log or syslog.
>
>Could you help to us how to solve this issue ?

Just as mentioned as in https://secure-web.cisco.com/1ll9UQp4RYnYXuVMxAlJKaDxV1RdMZtBcG3e_jDi4TlIxDMTzFMtJguJhndpS2BnNhGoAWwBP-G2UCWlarucvId1iz_ea_AU-U__8Gq6ZgF285KW8SRPHKr7NeWgE4dKG8o8PGMNJ3-lAB4xdptdPAk1vfJe8AL_Tt6oCEoT0OAr4RrSIjzqtmugt8EHD-jvxghKHjaWu1eGDkzOYtKpcV8WhZnz1wLItIZdChYT1xlXsFTU7-GnJhN2jLvMMlZgkMxzQLejJ2aB1wogBTkBIipva21mNGaSFb_sSZhX9ycwiT7UMUfQg5lyHCPZPEeP6/https%3A%2F%2Fxenomai.org%2Fpipermail%2Fxenomai%2F2022-April%2F047495.html
1. It is highly recommended to use a UART as kernel debug output.
2. enable CONFIG_XENO_OPT_WATCHDOG for xenomai, system will be able to tell RT application "hangs" (infinite loop at high prio) apart from real hangs/crashes.

Regards

Hongzhan Chen
>
>
>We set up our system as like below sw.
>
>1. Xubuntu 18.04 LTS 32bit
>
>2. Linux kernel 4.1.18 32bit
>
>3. Xenomai 3.0.8 32bit
>
>4. Kernel config
>   We refer to the xenomai page as like below.
>
>https://secure-web.cisco.com/1nAW3bSL64gGRUPlQWKtShagcypkiReyVX7nhG1T-J
>upEWaqU-3hnCSt542V_mEwX-_8HsjCaWtSuQnJ3056Yq52DypR5psiqKgrOSq6pbk6xe-tw
>xYZhwwm0akkU4iVwFscbrRTWdk2Ul-9fU2HilSTJ8rzI8X9LIfFg2foor5t9LawggXyjgq3
>QqwJktjRWEhqL8gFDP2PpsmxrTgVK6NzJdcBxzyOGo_jmjjiO009l74YL2U5Ke3A7kc1AX7
>IV_t016CRGEK4QyAKRuSTqKzFm8t4flDV7eBT4m43w-o_SoFrKq-AA7ZIKEYPEgpqq/http
>s%3A%2F%2Fsource.denx.de%2FXenomai%2Fxenomai%2F-
>/wikis/Configuring_For_X86_Based_Dual_Kernels#user-content-x86-
>processor-type
>
>Thanks.
>
>-----Original Message-----
>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>Sent: Friday, August 26, 2022 2:40 PM
>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원 두산로보틱스
><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시 주의하시기 바랍니다.
>
>CAUTION: This email is sent by an external account. Please take extra
>caution when clicking the link or opening the attachment.
>
>>-----Original Message-----
>>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>>Sent: Friday, August 26, 2022 10:41 AM
>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>Cc: ???(Youngchul Park) ????? ??????
><youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ??????
><kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ??????
><sehyun2.kim@doosan.com>; ???(Dongjoo Kim) ????? ??????
><dongjoo5.kim@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>Dear Xenomai.org, Chen, Hongzhan
>>
>>I'm dong joo.
>>
>>Thank you for your reply to us our questions.
>>
>>And, We have checked the value of TICK_NSEC int our system.
>>
>>#define TICK_NSEC ((NSEC_PER_SEC+HZ/2)/HZ)
>>#define NSEC_PER_SEC   1000000000L
>>HZ  250 ( Max 1000 )
>>
>>The value of TICK_NSEC is defined by linux kernel.
>>And, Both NSEC_PER_SEC and HZ calculate the value of TICK_NSEC.
>>
>>So, The current value of TICK_NSEC is 4ms based on 250 HZ.
>>And, If we change the value of HZ to 1000, The value of TICK_NSEC may
>>be
>1ms.
>>
>>
>>We hope to process a task every 20us using rt_task_yield as like
>>Xenomai
>2.6.5.
>>
>>Is there any method to achieve 20us task delay using rt_task_yield or
>>another
>xenomai method ?
>>And, Is there any problem to reduce the delay more less than TICK_NSEC ?
>
>I just went through the implementation of rt_task_yield of Xeomai 2.6.5
>and found that it is totally different from Xenomai 3.0.8.
>If you want to yield about 20us for current RT thread ,you may try call
>clock_nanosleep .
>.
>Regards
>
>Hongzhan Chen
>>
>>
>>Really Thanks.
>>
>
>
>This e-mail and any attachments herein may contain confidential or
>privileged information and is for the exclusive use of the intended
>recipient(s) named above. If you are not the intended recipient(s), you
>should not disseminate, distribute, retain, copy or otherwise use any
>information contained herein. If you have received this e-mail in
>error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments.
>Our company does not guarantee this e-mail is secure or free from viruses.
>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한
>수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.


This e-mail and any attachments herein may contain confidential or privileged information and is for the exclusive use of the intended recipient(s) named above. If you are not the intended recipient(s), you should not disseminate, distribute, retain, copy or otherwise use any information contained herein. If you have received this e-mail in error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments. Our company does not guarantee this e-mail is secure or free from viruses.
이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[Chen, Hongzhan]

>-----Original Message-----
>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Sent: Saturday, October 29, 2022 1:41 PM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>두산로보틱스 <kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim)
>연구원 두산로보틱스 <sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무
>두산로보틱스 <jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim)
>수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>; 김동주(Dongjoo
>Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>If our rt task using xenomai make a sw hang, how can i debug the reason ?
>
>Is there any method using gdb with core dump ?
>
>After enabling CONFIG_XENO_OPT_WATCHDOG,
>Watchdog handler point the hang rt task which is our task using xenomai.

The watchdog trigged because rt task has been dominating cpu too much time in RT domain.
You may want to yield this CPU to Linux domain and let it run in Linux domain for a while.

Regards

Hongzhan Chen
>
>
>static void watchdog_handler(struct xntimer *timer)
>{
>        struct xnsched *sched = xnsched_current();
>        struct xnthread *curr = sched->curr;
>
>        if (likely(xnthread_test_state(curr, XNROOT))) {
>                xnsched_reset_watchdog(sched);
>                return;
>        }
>
>        if (likely(++sched->wdcount < wd_timeout_arg))
>                return;
>
>        trace_cobalt_watchdog_signal(curr);
>
>        if (xnthread_test_state(curr, XNUSER)) {
>                printk(XENO_WARNING "watchdog triggered on CPU #%d -- runaway
>thread "
>                       "'%s' signaled\n", xnsched_cpu(sched), curr->name);
>                xnthread_call_mayday(curr, SIGDEBUG_WATCHDOG);
>        } else {
>                printk(XENO_WARNING "watchdog triggered on CPU #%d -- runaway
>thread "
>                       "'%s' canceled\n", xnsched_cpu(sched), curr->name);
>                /*
>                 * On behalf on an IRQ handler,
>
>Thanks.
>-----Original Message-----
>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>Sent: Tuesday, October 25, 2022 5:24 PM
>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>두산로보틱스 <kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim)
>연구원 두산로보틱스 <sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무
>두산로보틱스 <jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim)
>수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>주의하시기 바랍니다.
>
>CAUTION: This email is sent by an external account. Please take extra caution
>when clicking the link or opening the attachment.
>
>>-----Original Message-----
>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>
>>Sent: Tuesday, October 25, 2022 3:29 PM
>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>두산로보틱스
>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>두산로보틱스
>><dongjoo5.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스
>><youngjae7.lee@doosan.com>; 김상준(Sangjoon
>>Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>Dear Xenomai.org, Chen, Hongzhan
>>
>>I'm dong joo.
>>
>>After we do a aging test as like latency, We get a system hang about
>>ten hours later.
>>
>>At that time, Our system don't detect usb mouse.
>>
>>After rebooting our system by force,
>>there is no significative log in the kernel log or syslog.
>>
>>Could you help to us how to solve this issue ?
>
>Just as mentioned as in https://secure-
>web.cisco.com/1ll9UQp4RYnYXuVMxAlJKaDxV1RdMZtBcG3e_jDi4TlIxDMTzFM
>tJguJhndpS2BnNhGoAWwBP-G2UCWlarucvId1iz_ea_AU-
>U__8Gq6ZgF285KW8SRPHKr7NeWgE4dKG8o8PGMNJ3-
>lAB4xdptdPAk1vfJe8AL_Tt6oCEoT0OAr4RrSIjzqtmugt8EHD-
>jvxghKHjaWu1eGDkzOYtKpcV8WhZnz1wLItIZdChYT1xlXsFTU7-
>GnJhN2jLvMMlZgkMxzQLejJ2aB1wogBTkBIipva21mNGaSFb_sSZhX9ycwiT7UM
>UfQg5lyHCPZPEeP6/https%3A%2F%2Fxenomai.org%2Fpipermail%2Fxenomai%
>2F2022-April%2F047495.html
>1. It is highly recommended to use a UART as kernel debug output.
>2. enable CONFIG_XENO_OPT_WATCHDOG for xenomai, system will be able
>to tell RT application "hangs" (infinite loop at high prio) apart from real
>hangs/crashes.
>
>Regards
>
>Hongzhan Chen
>>
>>
>>We set up our system as like below sw.
>>
>>1. Xubuntu 18.04 LTS 32bit
>>
>>2. Linux kernel 4.1.18 32bit
>>
>>3. Xenomai 3.0.8 32bit
>>
>>4. Kernel config
>>   We refer to the xenomai page as like below.
>>
>>https://secure-
>web.cisco.com/1nAW3bSL64gGRUPlQWKtShagcypkiReyVX7nhG1T-J
>>upEWaqU-3hnCSt542V_mEwX-
>_8HsjCaWtSuQnJ3056Yq52DypR5psiqKgrOSq6pbk6xe-tw
>>xYZhwwm0akkU4iVwFscbrRTWdk2Ul-
>9fU2HilSTJ8rzI8X9LIfFg2foor5t9LawggXyjgq3
>>QqwJktjRWEhqL8gFDP2PpsmxrTgVK6NzJdcBxzyOGo_jmjjiO009l74YL2U5Ke3A
>7kc1AX7
>>IV_t016CRGEK4QyAKRuSTqKzFm8t4flDV7eBT4m43w-o_SoFrKq-
>AA7ZIKEYPEgpqq/http
>>s%3A%2F%2Fsource.denx.de%2FXenomai%2Fxenomai%2F-
>>/wikis/Configuring_For_X86_Based_Dual_Kernels#user-content-x86-
>>processor-type
>>
>>Thanks.
>>
>>-----Original Message-----
>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>Sent: Friday, August 26, 2022 2:40 PM
>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>두산로보틱스
>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>주의하시기 바랍니다.
>>
>>CAUTION: This email is sent by an external account. Please take extra
>>caution when clicking the link or opening the attachment.
>>
>>>-----Original Message-----
>>>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>>>Sent: Friday, August 26, 2022 10:41 AM
>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>>Cc: ???(Youngchul Park) ????? ??????
>><youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ??????
>><kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ??????
>><sehyun2.kim@doosan.com>; ???(Dongjoo Kim) ????? ??????
>><dongjoo5.kim@doosan.com>
>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>
>>>Dear Xenomai.org, Chen, Hongzhan
>>>
>>>I'm dong joo.
>>>
>>>Thank you for your reply to us our questions.
>>>
>>>And, We have checked the value of TICK_NSEC int our system.
>>>
>>>#define TICK_NSEC ((NSEC_PER_SEC+HZ/2)/HZ)
>>>#define NSEC_PER_SEC   1000000000L
>>>HZ  250 ( Max 1000 )
>>>
>>>The value of TICK_NSEC is defined by linux kernel.
>>>And, Both NSEC_PER_SEC and HZ calculate the value of TICK_NSEC.
>>>
>>>So, The current value of TICK_NSEC is 4ms based on 250 HZ.
>>>And, If we change the value of HZ to 1000, The value of TICK_NSEC may
>>>be
>>1ms.
>>>
>>>
>>>We hope to process a task every 20us using rt_task_yield as like
>>>Xenomai
>>2.6.5.
>>>
>>>Is there any method to achieve 20us task delay using rt_task_yield or
>>>another
>>xenomai method ?
>>>And, Is there any problem to reduce the delay more less than TICK_NSEC ?
>>
>>I just went through the implementation of rt_task_yield of Xeomai 2.6.5
>>and found that it is totally different from Xenomai 3.0.8.
>>If you want to yield about 20us for current RT thread ,you may try call
>>clock_nanosleep .
>>.
>>Regards
>>
>>Hongzhan Chen
>>>
>>>
>>>Really Thanks.
>>>
>>
>>
>>This e-mail and any attachments herein may contain confidential or
>>privileged information and is for the exclusive use of the intended
>>recipient(s) named above. If you are not the intended recipient(s), you
>>should not disseminate, distribute, retain, copy or otherwise use any
>>information contained herein. If you have received this e-mail in
>>error, please notify the sender immediately by replying to this message and
>delete this e-mail and associated attachments.
>>Our company does not guarantee this e-mail is secure or free from viruses.
>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한
>>수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를
>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>
>
>This e-mail and any attachments herein may contain confidential or privileged
>information and is for the exclusive use of the intended recipient(s) named
>above. If you are not the intended recipient(s), you should not disseminate,
>distribute, retain, copy or otherwise use any information contained herein. If
>you have received this e-mail in error, please notify the sender immediately by
>replying to this message and delete this e-mail and associated attachments.
>Our company does not guarantee this e-mail is secure or free from viruses.
>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한
>수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를
>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에
>관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신
>경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기
>바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[김동주(Dongjoo Kim) 책임연구원 두산로보틱스]

Dear Xenomai.org, Chen, Hongzhan

I'm dong joo.

We have tested the API of Xenomai rt_mutex as like rt_mutex_create, rt_mutex_acquire, rt_mutex_release.


If we block the rt_mutex_release,
The next sequence can't get a rt_mutex_acquire by the previous sequence don't call rt_mutex_release before.

So, The result of count must be 0 what we think.

But, The result of count increase abnormally as like below. Is there any problem about rt_mutex_acquire or rt_mutex_release ?


If we test the API of Xenomai rt_sem as like rt_sem_create, rt_sem_p, rt_sem_v,
The result of count is 0.


rt_mutex_create 0
task info
rt_mutex_acquire 0
Loop count: 0, Loop time: 355521102 ms
rt_mutex_acquire 0
Loop count: 1, Loop time: 355521103 ms
rt_mutex_acquire 0
Loop count: 2, Loop time: 355521104 ms
rt_mutex_acquire 0
Loop count: 3, Loop time: 355521105 ms
rt_mutex_acquire 0
Loop count: 4, Loop time: 355521106 ms
rt_mutex_acquire 0
Loop count: 5, Loop time: 355521107 ms
rt_mutex_acquire 0
Loop count: 6, Loop time: 355521108 ms
rt_mutex_acquire 0
Loop count: 7, Loop time: 355521109 ms
rt_mutex_acquire 0
Loop count: 8, Loop time: 355521110 ms
rt_mutex_acquire 0


void loop_task_proc(void *arg) {

        int cnt = 0;
        int ret = 0 ;

        RTIME tstart1;

        RT_MUTEX            m_tMutex;
//      RT_SEM              m_tSemaphore;
        ret = rt_mutex_create(&m_tMutex, "test");
        rt_printf("rt_mutex_create %d\n", ret ) ;

//      ret = rt_sem_create(&m_tSemaphore, "test", 1, S_FIFO);
//      rt_printf("rt_sem_create %d\n", ret ) ;

        //Print the info
        rt_printf("task info \n");

        rt_task_set_periodic(NULL, TM_NOW, LOOP_PERIOD);


        //Start the task loop
        while (1) {
        ret =   rt_mutex_acquire(&m_tMutex, TM_INFINITE );
        rt_printf("rt_mutex_acquire %d\n", ret ) ;

//      rt_sem_p(&m_tSemaphore, TM_INFINITE ) ;
//      rt_printf("rt_sem_p %d\n", ret ) ;
//
        tstart1 = rt_timer_read () ;
        rt_printf("Loop count: %d, Loop time: %llu ms\n", cnt, tstart1 / 1000000 );
        cnt++;
        rt_task_wait_period(NULL);

//      ret =           rt_mutex_release(&m_tMutex);
//      rt_printf("rt_mutex_release %d\n", ret ) ;
//      rt_sem_v(&m_tSemaphore);
//      rt_printf("rt_sem_v %d\n", ret ) ;
        }
}

int main(int argc, char* argv[])
{

        RT_TASK loop_task;
        rt_task_create(&loop_task, "basicmath_small", 0, 50, 0);
        rt_task_start(&loop_task, &loop_task_proc, 0);
        //Wait for Ctrl-C
        pause();
        return 0;


}

Thanks.

-----Original Message-----
From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
Sent: Wednesday, October 26, 2022 11:43 AM
To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원 두산로보틱스 <kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스 <sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스 <jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>; 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
Subject: RE: What causes the latency of the rt_task_yield() API?

Dear Xenomai.org, Chen, Hongzhan

I'm dong joo.

I have a basic question.

If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI Processor CONFIG, We can't check the current cpu freq by sysnode.

Because, sysnode of cpu freq is related to CPU_FREQ CONFIG and ACPI Processor CONFIG as i know.


If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI Processor CONFIG, Could you expect the current cpu freq in the intel hw system ?

Actually, The minimum cpu clock of our hw system is very low.

If our hw system operate with minimum cpu clock always, I worry about the performance of hw system.


sys/devices/system/cpu/cpu0/cpufreq# ls
affected_cpus  cpuinfo_cur_freq  cpuinfo_min_freq            freqdomain_cpus  scaling_available_frequencies  scaling_cur_freq  scaling_governor  scaling_min_freq  stats
bios_limit     cpuinfo_max_freq  cpuinfo_transition_latency  related_cpus     scaling_available_governors    scaling_driver    scaling_max_freq  scaling_setspeed


Thanks.

-----Original Message-----
From: Chen, Hongzhan <hongzhan.chen@intel.com>
Sent: Tuesday, October 25, 2022 5:24 PM
To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>; xenomai@xenomai.org
Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원 두산로보틱스 <kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스 <sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스 <jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>
Subject: RE: What causes the latency of the rt_task_yield() API?

주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시 주의하시기 바랍니다.

CAUTION: This email is sent by an external account. Please take extra caution when clicking the link or opening the attachment.

>-----Original Message-----
>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Sent: Tuesday, October 25, 2022 3:29 PM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원 두산로보틱스
><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스
><youngjae7.lee@doosan.com>; 김상준(Sangjoon
>Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>After we do a aging test as like latency, We get a system hang about
>ten hours later.
>
>At that time, Our system don't detect usb mouse.
>
>After rebooting our system by force,
>there is no significative log in the kernel log or syslog.
>
>Could you help to us how to solve this issue ?

Just as mentioned as in https://secure-web.cisco.com/1ll9UQp4RYnYXuVMxAlJKaDxV1RdMZtBcG3e_jDi4TlIxDMTzFMtJguJhndpS2BnNhGoAWwBP-G2UCWlarucvId1iz_ea_AU-U__8Gq6ZgF285KW8SRPHKr7NeWgE4dKG8o8PGMNJ3-lAB4xdptdPAk1vfJe8AL_Tt6oCEoT0OAr4RrSIjzqtmugt8EHD-jvxghKHjaWu1eGDkzOYtKpcV8WhZnz1wLItIZdChYT1xlXsFTU7-GnJhN2jLvMMlZgkMxzQLejJ2aB1wogBTkBIipva21mNGaSFb_sSZhX9ycwiT7UMUfQg5lyHCPZPEeP6/https%3A%2F%2Fxenomai.org%2Fpipermail%2Fxenomai%2F2022-April%2F047495.html
1. It is highly recommended to use a UART as kernel debug output.
2. enable CONFIG_XENO_OPT_WATCHDOG for xenomai, system will be able to tell RT application "hangs" (infinite loop at high prio) apart from real hangs/crashes.

Regards

Hongzhan Chen
>
>
>We set up our system as like below sw.
>
>1. Xubuntu 18.04 LTS 32bit
>
>2. Linux kernel 4.1.18 32bit
>
>3. Xenomai 3.0.8 32bit
>
>4. Kernel config
>   We refer to the xenomai page as like below.
>
>https://secure-web.cisco.com/1nAW3bSL64gGRUPlQWKtShagcypkiReyVX7nhG1T-J
>upEWaqU-3hnCSt542V_mEwX-_8HsjCaWtSuQnJ3056Yq52DypR5psiqKgrOSq6pbk6xe-tw
>xYZhwwm0akkU4iVwFscbrRTWdk2Ul-9fU2HilSTJ8rzI8X9LIfFg2foor5t9LawggXyjgq3
>QqwJktjRWEhqL8gFDP2PpsmxrTgVK6NzJdcBxzyOGo_jmjjiO009l74YL2U5Ke3A7kc1AX7
>IV_t016CRGEK4QyAKRuSTqKzFm8t4flDV7eBT4m43w-o_SoFrKq-AA7ZIKEYPEgpqq/http
>s%3A%2F%2Fsource.denx.de%2FXenomai%2Fxenomai%2F-
>/wikis/Configuring_For_X86_Based_Dual_Kernels#user-content-x86-
>processor-type
>
>Thanks.
>
>-----Original Message-----
>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>Sent: Friday, August 26, 2022 2:40 PM
>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원 두산로보틱스
><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시 주의하시기 바랍니다.
>
>CAUTION: This email is sent by an external account. Please take extra
>caution when clicking the link or opening the attachment.
>
>>-----Original Message-----
>>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>>Sent: Friday, August 26, 2022 10:41 AM
>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>Cc: ???(Youngchul Park) ????? ??????
><youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ??????
><kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ??????
><sehyun2.kim@doosan.com>; ???(Dongjoo Kim) ????? ??????
><dongjoo5.kim@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>Dear Xenomai.org, Chen, Hongzhan
>>
>>I'm dong joo.
>>
>>Thank you for your reply to us our questions.
>>
>>And, We have checked the value of TICK_NSEC int our system.
>>
>>#define TICK_NSEC ((NSEC_PER_SEC+HZ/2)/HZ)
>>#define NSEC_PER_SEC   1000000000L
>>HZ  250 ( Max 1000 )
>>
>>The value of TICK_NSEC is defined by linux kernel.
>>And, Both NSEC_PER_SEC and HZ calculate the value of TICK_NSEC.
>>
>>So, The current value of TICK_NSEC is 4ms based on 250 HZ.
>>And, If we change the value of HZ to 1000, The value of TICK_NSEC may
>>be
>1ms.
>>
>>
>>We hope to process a task every 20us using rt_task_yield as like
>>Xenomai
>2.6.5.
>>
>>Is there any method to achieve 20us task delay using rt_task_yield or
>>another
>xenomai method ?
>>And, Is there any problem to reduce the delay more less than TICK_NSEC ?
>
>I just went through the implementation of rt_task_yield of Xeomai 2.6.5
>and found that it is totally different from Xenomai 3.0.8.
>If you want to yield about 20us for current RT thread ,you may try call
>clock_nanosleep .
>.
>Regards
>
>Hongzhan Chen
>>
>>
>>Really Thanks.
>>
>
>
>This e-mail and any attachments herein may contain confidential or
>privileged information and is for the exclusive use of the intended
>recipient(s) named above. If you are not the intended recipient(s), you
>should not disseminate, distribute, retain, copy or otherwise use any
>information contained herein. If you have received this e-mail in
>error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments.
>Our company does not guarantee this e-mail is secure or free from viruses.
>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한
>수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.


This e-mail and any attachments herein may contain confidential or privileged information and is for the exclusive use of the intended recipient(s) named above. If you are not the intended recipient(s), you should not disseminate, distribute, retain, copy or otherwise use any information contained herein. If you have received this e-mail in error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments. Our company does not guarantee this e-mail is secure or free from viruses.
이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[김동주(Dongjoo Kim) 책임연구원 두산로보틱스]

Dear Xenomai.org, Chen, Hongzhan

I'm dong joo.

Could you help me to solve this problem ?

Thanks.

-----Original Message-----
From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
Sent: Monday, January 2, 2023 12:10 PM
To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스 <sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>; 이형석(Hyungseok Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>; 송창우(Changwoo Song) 책임연구원 두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원 두산로보틱스 <kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
Subject: RE: What causes the latency of the rt_task_yield() API?

Dear Xenomai.org, Chen, Hongzhan

I'm dong joo.

We have tested the API of Xenomai rt_mutex as like rt_mutex_create, rt_mutex_acquire, rt_mutex_release.


If we block the rt_mutex_release,
The next sequence can't get a rt_mutex_acquire by the previous sequence don't call rt_mutex_release before.

So, The result of count must be 0 what we think.

But, The result of count increase abnormally as like below. Is there any problem about rt_mutex_acquire or rt_mutex_release ?


If we test the API of Xenomai rt_sem as like rt_sem_create, rt_sem_p, rt_sem_v, The result of count is 0.


rt_mutex_create 0
task info
rt_mutex_acquire 0
Loop count: 0, Loop time: 355521102 ms
rt_mutex_acquire 0
Loop count: 1, Loop time: 355521103 ms
rt_mutex_acquire 0
Loop count: 2, Loop time: 355521104 ms
rt_mutex_acquire 0
Loop count: 3, Loop time: 355521105 ms
rt_mutex_acquire 0
Loop count: 4, Loop time: 355521106 ms
rt_mutex_acquire 0
Loop count: 5, Loop time: 355521107 ms
rt_mutex_acquire 0
Loop count: 6, Loop time: 355521108 ms
rt_mutex_acquire 0
Loop count: 7, Loop time: 355521109 ms
rt_mutex_acquire 0
Loop count: 8, Loop time: 355521110 ms
rt_mutex_acquire 0


void loop_task_proc(void *arg) {

        int cnt = 0;
        int ret = 0 ;

        RTIME tstart1;

        RT_MUTEX            m_tMutex;
//      RT_SEM              m_tSemaphore;
        ret = rt_mutex_create(&m_tMutex, "test");
        rt_printf("rt_mutex_create %d\n", ret ) ;

//      ret = rt_sem_create(&m_tSemaphore, "test", 1, S_FIFO);
//      rt_printf("rt_sem_create %d\n", ret ) ;

        //Print the info
        rt_printf("task info \n");

        rt_task_set_periodic(NULL, TM_NOW, LOOP_PERIOD);


        //Start the task loop
        while (1) {
        ret =   rt_mutex_acquire(&m_tMutex, TM_INFINITE );
        rt_printf("rt_mutex_acquire %d\n", ret ) ;

//      rt_sem_p(&m_tSemaphore, TM_INFINITE ) ;
//      rt_printf("rt_sem_p %d\n", ret ) ;
//
        tstart1 = rt_timer_read () ;
        rt_printf("Loop count: %d, Loop time: %llu ms\n", cnt, tstart1 / 1000000 );
        cnt++;
        rt_task_wait_period(NULL);

//      ret =           rt_mutex_release(&m_tMutex);
//      rt_printf("rt_mutex_release %d\n", ret ) ;
//      rt_sem_v(&m_tSemaphore);
//      rt_printf("rt_sem_v %d\n", ret ) ;
        }
}

int main(int argc, char* argv[])
{

        RT_TASK loop_task;
        rt_task_create(&loop_task, "basicmath_small", 0, 50, 0);
        rt_task_start(&loop_task, &loop_task_proc, 0);
        //Wait for Ctrl-C
        pause();
        return 0;


}

Thanks.

-----Original Message-----
From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
Sent: Wednesday, October 26, 2022 11:43 AM
To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원 두산로보틱스 <kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스 <sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스 <jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>; 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
Subject: RE: What causes the latency of the rt_task_yield() API?

Dear Xenomai.org, Chen, Hongzhan

I'm dong joo.

I have a basic question.

If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI Processor CONFIG, We can't check the current cpu freq by sysnode.

Because, sysnode of cpu freq is related to CPU_FREQ CONFIG and ACPI Processor CONFIG as i know.


If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI Processor CONFIG, Could you expect the current cpu freq in the intel hw system ?

Actually, The minimum cpu clock of our hw system is very low.

If our hw system operate with minimum cpu clock always, I worry about the performance of hw system.


sys/devices/system/cpu/cpu0/cpufreq# ls
affected_cpus  cpuinfo_cur_freq  cpuinfo_min_freq            freqdomain_cpus  scaling_available_frequencies  scaling_cur_freq  scaling_governor  scaling_min_freq  stats
bios_limit     cpuinfo_max_freq  cpuinfo_transition_latency  related_cpus     scaling_available_governors    scaling_driver    scaling_max_freq  scaling_setspeed


Thanks.

-----Original Message-----
From: Chen, Hongzhan <hongzhan.chen@intel.com>
Sent: Tuesday, October 25, 2022 5:24 PM
To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>; xenomai@xenomai.org
Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원 두산로보틱스 <kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스 <sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스 <jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>
Subject: RE: What causes the latency of the rt_task_yield() API?

주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시 주의하시기 바랍니다.

CAUTION: This email is sent by an external account. Please take extra caution when clicking the link or opening the attachment.

>-----Original Message-----
>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Sent: Tuesday, October 25, 2022 3:29 PM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원 두산로보틱스
><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스
><youngjae7.lee@doosan.com>; 김상준(Sangjoon
>Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>After we do a aging test as like latency, We get a system hang about
>ten hours later.
>
>At that time, Our system don't detect usb mouse.
>
>After rebooting our system by force,
>there is no significative log in the kernel log or syslog.
>
>Could you help to us how to solve this issue ?

Just as mentioned as in https://secure-web.cisco.com/1ll9UQp4RYnYXuVMxAlJKaDxV1RdMZtBcG3e_jDi4TlIxDMTzFMtJguJhndpS2BnNhGoAWwBP-G2UCWlarucvId1iz_ea_AU-U__8Gq6ZgF285KW8SRPHKr7NeWgE4dKG8o8PGMNJ3-lAB4xdptdPAk1vfJe8AL_Tt6oCEoT0OAr4RrSIjzqtmugt8EHD-jvxghKHjaWu1eGDkzOYtKpcV8WhZnz1wLItIZdChYT1xlXsFTU7-GnJhN2jLvMMlZgkMxzQLejJ2aB1wogBTkBIipva21mNGaSFb_sSZhX9ycwiT7UMUfQg5lyHCPZPEeP6/https%3A%2F%2Fxenomai.org%2Fpipermail%2Fxenomai%2F2022-April%2F047495.html
1. It is highly recommended to use a UART as kernel debug output.
2. enable CONFIG_XENO_OPT_WATCHDOG for xenomai, system will be able to tell RT application "hangs" (infinite loop at high prio) apart from real hangs/crashes.

Regards

Hongzhan Chen
>
>
>We set up our system as like below sw.
>
>1. Xubuntu 18.04 LTS 32bit
>
>2. Linux kernel 4.1.18 32bit
>
>3. Xenomai 3.0.8 32bit
>
>4. Kernel config
>   We refer to the xenomai page as like below.
>
>https://secure-web.cisco.com/1nAW3bSL64gGRUPlQWKtShagcypkiReyVX7nhG1T-J
>upEWaqU-3hnCSt542V_mEwX-_8HsjCaWtSuQnJ3056Yq52DypR5psiqKgrOSq6pbk6xe-tw
>xYZhwwm0akkU4iVwFscbrRTWdk2Ul-9fU2HilSTJ8rzI8X9LIfFg2foor5t9LawggXyjgq3
>QqwJktjRWEhqL8gFDP2PpsmxrTgVK6NzJdcBxzyOGo_jmjjiO009l74YL2U5Ke3A7kc1AX7
>IV_t016CRGEK4QyAKRuSTqKzFm8t4flDV7eBT4m43w-o_SoFrKq-AA7ZIKEYPEgpqq/http
>s%3A%2F%2Fsource.denx.de%2FXenomai%2Fxenomai%2F-
>/wikis/Configuring_For_X86_Based_Dual_Kernels#user-content-x86-
>processor-type
>
>Thanks.
>
>-----Original Message-----
>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>Sent: Friday, August 26, 2022 2:40 PM
>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원 두산로보틱스
><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시 주의하시기 바랍니다.
>
>CAUTION: This email is sent by an external account. Please take extra
>caution when clicking the link or opening the attachment.
>
>>-----Original Message-----
>>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>>Sent: Friday, August 26, 2022 10:41 AM
>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>Cc: ???(Youngchul Park) ????? ??????
><youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ??????
><kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ??????
><sehyun2.kim@doosan.com>; ???(Dongjoo Kim) ????? ??????
><dongjoo5.kim@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>Dear Xenomai.org, Chen, Hongzhan
>>
>>I'm dong joo.
>>
>>Thank you for your reply to us our questions.
>>
>>And, We have checked the value of TICK_NSEC int our system.
>>
>>#define TICK_NSEC ((NSEC_PER_SEC+HZ/2)/HZ)
>>#define NSEC_PER_SEC   1000000000L
>>HZ  250 ( Max 1000 )
>>
>>The value of TICK_NSEC is defined by linux kernel.
>>And, Both NSEC_PER_SEC and HZ calculate the value of TICK_NSEC.
>>
>>So, The current value of TICK_NSEC is 4ms based on 250 HZ.
>>And, If we change the value of HZ to 1000, The value of TICK_NSEC may
>>be
>1ms.
>>
>>
>>We hope to process a task every 20us using rt_task_yield as like
>>Xenomai
>2.6.5.
>>
>>Is there any method to achieve 20us task delay using rt_task_yield or
>>another
>xenomai method ?
>>And, Is there any problem to reduce the delay more less than TICK_NSEC ?
>
>I just went through the implementation of rt_task_yield of Xeomai 2.6.5
>and found that it is totally different from Xenomai 3.0.8.
>If you want to yield about 20us for current RT thread ,you may try call
>clock_nanosleep .
>.
>Regards
>
>Hongzhan Chen
>>
>>
>>Really Thanks.
>>
>
>
>This e-mail and any attachments herein may contain confidential or
>privileged information and is for the exclusive use of the intended
>recipient(s) named above. If you are not the intended recipient(s), you
>should not disseminate, distribute, retain, copy or otherwise use any
>information contained herein. If you have received this e-mail in
>error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments.
>Our company does not guarantee this e-mail is secure or free from viruses.
>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한
>수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.


This e-mail and any attachments herein may contain confidential or privileged information and is for the exclusive use of the intended recipient(s) named above. If you are not the intended recipient(s), you should not disseminate, distribute, retain, copy or otherwise use any information contained herein. If you have received this e-mail in error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments. Our company does not guarantee this e-mail is secure or free from viruses.
이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[Chen, Hongzhan]

Hi 

Why do not you use posix mutex like example in testsuite/smokey/posix-mutex/posix-mutex.c?


Regards

Hongzhan Chen

>-----Original Message-----
>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Sent: Thursday, January 5, 2023 9:21 AM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim)
>수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>; 이형석(Hyungseok
>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song) 책임연구원 두산로보틱스
><changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원
>두산로보틱스 <kyungchan.son@doosan.com>; 김동주(Dongjoo Kim)
>책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>Could you help me to solve this problem ?
>
>Thanks.
>
>-----Original Message-----
>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Sent: Monday, January 2, 2023 12:10 PM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim)
>수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>; 이형석(Hyungseok
>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song) 책임연구원 두산로보틱스
><changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원
>두산로보틱스 <kyungchan.son@doosan.com>; 김동주(Dongjoo Kim)
>책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>We have tested the API of Xenomai rt_mutex as like rt_mutex_create,
>rt_mutex_acquire, rt_mutex_release.
>
>
>If we block the rt_mutex_release,
>The next sequence can't get a rt_mutex_acquire by the previous sequence
>don't call rt_mutex_release before.
>
>So, The result of count must be 0 what we think.
>
>But, The result of count increase abnormally as like below. Is there any
>problem about rt_mutex_acquire or rt_mutex_release ?
>
>
>If we test the API of Xenomai rt_sem as like rt_sem_create, rt_sem_p,
>rt_sem_v, The result of count is 0.
>
>
>rt_mutex_create 0
>task info
>rt_mutex_acquire 0
>Loop count: 0, Loop time: 355521102 ms
>rt_mutex_acquire 0
>Loop count: 1, Loop time: 355521103 ms
>rt_mutex_acquire 0
>Loop count: 2, Loop time: 355521104 ms
>rt_mutex_acquire 0
>Loop count: 3, Loop time: 355521105 ms
>rt_mutex_acquire 0
>Loop count: 4, Loop time: 355521106 ms
>rt_mutex_acquire 0
>Loop count: 5, Loop time: 355521107 ms
>rt_mutex_acquire 0
>Loop count: 6, Loop time: 355521108 ms
>rt_mutex_acquire 0
>Loop count: 7, Loop time: 355521109 ms
>rt_mutex_acquire 0
>Loop count: 8, Loop time: 355521110 ms
>rt_mutex_acquire 0
>
>
>void loop_task_proc(void *arg) {
>
>        int cnt = 0;
>        int ret = 0 ;
>
>        RTIME tstart1;
>
>        RT_MUTEX            m_tMutex;
>//      RT_SEM              m_tSemaphore;
>        ret = rt_mutex_create(&m_tMutex, "test");
>        rt_printf("rt_mutex_create %d\n", ret ) ;
>
>//      ret = rt_sem_create(&m_tSemaphore, "test", 1, S_FIFO);
>//      rt_printf("rt_sem_create %d\n", ret ) ;
>
>        //Print the info
>        rt_printf("task info \n");
>
>        rt_task_set_periodic(NULL, TM_NOW, LOOP_PERIOD);
>
>
>        //Start the task loop
>        while (1) {
>        ret =   rt_mutex_acquire(&m_tMutex, TM_INFINITE );
>        rt_printf("rt_mutex_acquire %d\n", ret ) ;
>
>//      rt_sem_p(&m_tSemaphore, TM_INFINITE ) ;
>//      rt_printf("rt_sem_p %d\n", ret ) ;
>//
>        tstart1 = rt_timer_read () ;
>        rt_printf("Loop count: %d, Loop time: %llu ms\n", cnt, tstart1 / 1000000 );
>        cnt++;
>        rt_task_wait_period(NULL);
>
>//      ret =           rt_mutex_release(&m_tMutex);
>//      rt_printf("rt_mutex_release %d\n", ret ) ;
>//      rt_sem_v(&m_tSemaphore);
>//      rt_printf("rt_sem_v %d\n", ret ) ;
>        }
>}
>
>int main(int argc, char* argv[])
>{
>
>        RT_TASK loop_task;
>        rt_task_create(&loop_task, "basicmath_small", 0, 50, 0);
>        rt_task_start(&loop_task, &loop_task_proc, 0);
>        //Wait for Ctrl-C
>        pause();
>        return 0;
>
>
>}
>
>Thanks.
>
>-----Original Message-----
>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>Sent: Wednesday, October 26, 2022 11:43 AM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>두산로보틱스 <kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim)
>연구원 두산로보틱스 <sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무
>두산로보틱스 <jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim)
>수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>; 김동주(Dongjoo
>Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>I have a basic question.
>
>If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI Processor
>CONFIG, We can't check the current cpu freq by sysnode.
>
>Because, sysnode of cpu freq is related to CPU_FREQ CONFIG and ACPI
>Processor CONFIG as i know.
>
>
>If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI Processor
>CONFIG, Could you expect the current cpu freq in the intel hw system ?
>
>Actually, The minimum cpu clock of our hw system is very low.
>
>If our hw system operate with minimum cpu clock always, I worry about the
>performance of hw system.
>
>
>sys/devices/system/cpu/cpu0/cpufreq# ls
>affected_cpus  cpuinfo_cur_freq  cpuinfo_min_freq            freqdomain_cpus
>scaling_available_frequencies  scaling_cur_freq  scaling_governor
>scaling_min_freq  stats
>bios_limit     cpuinfo_max_freq  cpuinfo_transition_latency  related_cpus
>scaling_available_governors    scaling_driver    scaling_max_freq
>scaling_setspeed
>
>
>Thanks.
>
>-----Original Message-----
>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>Sent: Tuesday, October 25, 2022 5:24 PM
>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>두산로보틱스 <kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim)
>연구원 두산로보틱스 <sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무
>두산로보틱스 <jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim)
>수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>주의하시기 바랍니다.
>
>CAUTION: This email is sent by an external account. Please take extra caution
>when clicking the link or opening the attachment.
>
>>-----Original Message-----
>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>
>>Sent: Tuesday, October 25, 2022 3:29 PM
>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>두산로보틱스
>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>두산로보틱스
>><dongjoo5.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스
>><youngjae7.lee@doosan.com>; 김상준(Sangjoon
>>Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>Dear Xenomai.org, Chen, Hongzhan
>>
>>I'm dong joo.
>>
>>After we do a aging test as like latency, We get a system hang about
>>ten hours later.
>>
>>At that time, Our system don't detect usb mouse.
>>
>>After rebooting our system by force,
>>there is no significative log in the kernel log or syslog.
>>
>>Could you help to us how to solve this issue ?
>
>Just as mentioned as in https://secure-
>web.cisco.com/1ll9UQp4RYnYXuVMxAlJKaDxV1RdMZtBcG3e_jDi4TlIxDMTzFM
>tJguJhndpS2BnNhGoAWwBP-G2UCWlarucvId1iz_ea_AU-
>U__8Gq6ZgF285KW8SRPHKr7NeWgE4dKG8o8PGMNJ3-
>lAB4xdptdPAk1vfJe8AL_Tt6oCEoT0OAr4RrSIjzqtmugt8EHD-
>jvxghKHjaWu1eGDkzOYtKpcV8WhZnz1wLItIZdChYT1xlXsFTU7-
>GnJhN2jLvMMlZgkMxzQLejJ2aB1wogBTkBIipva21mNGaSFb_sSZhX9ycwiT7UM
>UfQg5lyHCPZPEeP6/https%3A%2F%2Fxenomai.org%2Fpipermail%2Fxenomai%
>2F2022-April%2F047495.html
>1. It is highly recommended to use a UART as kernel debug output.
>2. enable CONFIG_XENO_OPT_WATCHDOG for xenomai, system will be able
>to tell RT application "hangs" (infinite loop at high prio) apart from real
>hangs/crashes.
>
>Regards
>
>Hongzhan Chen
>>
>>
>>We set up our system as like below sw.
>>
>>1. Xubuntu 18.04 LTS 32bit
>>
>>2. Linux kernel 4.1.18 32bit
>>
>>3. Xenomai 3.0.8 32bit
>>
>>4. Kernel config
>>   We refer to the xenomai page as like below.
>>
>>https://secure-
>web.cisco.com/1nAW3bSL64gGRUPlQWKtShagcypkiReyVX7nhG1T-J
>>upEWaqU-3hnCSt542V_mEwX-
>_8HsjCaWtSuQnJ3056Yq52DypR5psiqKgrOSq6pbk6xe-tw
>>xYZhwwm0akkU4iVwFscbrRTWdk2Ul-
>9fU2HilSTJ8rzI8X9LIfFg2foor5t9LawggXyjgq3
>>QqwJktjRWEhqL8gFDP2PpsmxrTgVK6NzJdcBxzyOGo_jmjjiO009l74YL2U5Ke3A
>7kc1AX7
>>IV_t016CRGEK4QyAKRuSTqKzFm8t4flDV7eBT4m43w-o_SoFrKq-
>AA7ZIKEYPEgpqq/http
>>s%3A%2F%2Fsource.denx.de%2FXenomai%2Fxenomai%2F-
>>/wikis/Configuring_For_X86_Based_Dual_Kernels#user-content-x86-
>>processor-type
>>
>>Thanks.
>>
>>-----Original Message-----
>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>Sent: Friday, August 26, 2022 2:40 PM
>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>두산로보틱스
>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>주의하시기 바랍니다.
>>
>>CAUTION: This email is sent by an external account. Please take extra
>>caution when clicking the link or opening the attachment.
>>
>>>-----Original Message-----
>>>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>>>Sent: Friday, August 26, 2022 10:41 AM
>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>>Cc: ???(Youngchul Park) ????? ??????
>><youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ??????
>><kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ??????
>><sehyun2.kim@doosan.com>; ???(Dongjoo Kim) ????? ??????
>><dongjoo5.kim@doosan.com>
>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>
>>>Dear Xenomai.org, Chen, Hongzhan
>>>
>>>I'm dong joo.
>>>
>>>Thank you for your reply to us our questions.
>>>
>>>And, We have checked the value of TICK_NSEC int our system.
>>>
>>>#define TICK_NSEC ((NSEC_PER_SEC+HZ/2)/HZ)
>>>#define NSEC_PER_SEC   1000000000L
>>>HZ  250 ( Max 1000 )
>>>
>>>The value of TICK_NSEC is defined by linux kernel.
>>>And, Both NSEC_PER_SEC and HZ calculate the value of TICK_NSEC.
>>>
>>>So, The current value of TICK_NSEC is 4ms based on 250 HZ.
>>>And, If we change the value of HZ to 1000, The value of TICK_NSEC may
>>>be
>>1ms.
>>>
>>>
>>>We hope to process a task every 20us using rt_task_yield as like
>>>Xenomai
>>2.6.5.
>>>
>>>Is there any method to achieve 20us task delay using rt_task_yield or
>>>another
>>xenomai method ?
>>>And, Is there any problem to reduce the delay more less than TICK_NSEC ?
>>
>>I just went through the implementation of rt_task_yield of Xeomai 2.6.5
>>and found that it is totally different from Xenomai 3.0.8.
>>If you want to yield about 20us for current RT thread ,you may try call
>>clock_nanosleep .
>>.
>>Regards
>>
>>Hongzhan Chen
>>>
>>>
>>>Really Thanks.
>>>
>>
>>
>>This e-mail and any attachments herein may contain confidential or
>>privileged information and is for the exclusive use of the intended
>>recipient(s) named above. If you are not the intended recipient(s), you
>>should not disseminate, distribute, retain, copy or otherwise use any
>>information contained herein. If you have received this e-mail in
>>error, please notify the sender immediately by replying to this message and
>delete this e-mail and associated attachments.
>>Our company does not guarantee this e-mail is secure or free from viruses.
>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한
>>수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를
>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>
>
>This e-mail and any attachments herein may contain confidential or privileged
>information and is for the exclusive use of the intended recipient(s) named
>above. If you are not the intended recipient(s), you should not disseminate,
>distribute, retain, copy or otherwise use any information contained herein. If
>you have received this e-mail in error, please notify the sender immediately by
>replying to this message and delete this e-mail and associated attachments.
>Our company does not guarantee this e-mail is secure or free from viruses.
>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한
>수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를
>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에
>관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신
>경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기
>바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[김동주(Dongjoo Kim) 책임연구원 두산로보틱스]

Dear Xenomai.org, Chen, Hongzhan

I'm dong joo.

Thanks for your support.

I have one more questions.

Is the posix-mutex realtime mutex or not ?

And, Is there no problem to use the posix-mutex in the realtime Task ?


Finally, Is there any problem to use the rt_mutex_lock based on Xenomai guide?


Thanks.

-----Original Message-----
From: Chen, Hongzhan <hongzhan.chen@intel.com>
Sent: Thursday, January 5, 2023 4:03 PM
To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>; xenomai@xenomai.org
Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스 <sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>; 이형석(Hyungseok Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>; 송창우(Changwoo Song) 책임연구원 두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원 두산로보틱스 <kyungchan.son@doosan.com>
Subject: RE: What causes the latency of the rt_task_yield() API?

주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시 주의하시기 바랍니다.

CAUTION: This email is sent by an external account. Please take extra caution when clicking the link or opening the attachment.

Hi

Why do not you use posix mutex like example in testsuite/smokey/posix-mutex/posix-mutex.c?


Regards

Hongzhan Chen

>-----Original Message-----
>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Sent: Thursday, January 5, 2023 9:21 AM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스
><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스
><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>; 송창우(Changwoo Song) 책임연구원
>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원 두산로보틱스
><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>Could you help me to solve this problem ?
>
>Thanks.
>
>-----Original Message-----
>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Sent: Monday, January 2, 2023 12:10 PM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스
><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스
><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>; 송창우(Changwoo Song) 책임연구원
>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원 두산로보틱스
><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>We have tested the API of Xenomai rt_mutex as like rt_mutex_create,
>rt_mutex_acquire, rt_mutex_release.
>
>
>If we block the rt_mutex_release,
>The next sequence can't get a rt_mutex_acquire by the previous sequence
>don't call rt_mutex_release before.
>
>So, The result of count must be 0 what we think.
>
>But, The result of count increase abnormally as like below. Is there
>any problem about rt_mutex_acquire or rt_mutex_release ?
>
>
>If we test the API of Xenomai rt_sem as like rt_sem_create, rt_sem_p,
>rt_sem_v, The result of count is 0.
>
>
>rt_mutex_create 0
>task info
>rt_mutex_acquire 0
>Loop count: 0, Loop time: 355521102 ms
>rt_mutex_acquire 0
>Loop count: 1, Loop time: 355521103 ms
>rt_mutex_acquire 0
>Loop count: 2, Loop time: 355521104 ms
>rt_mutex_acquire 0
>Loop count: 3, Loop time: 355521105 ms
>rt_mutex_acquire 0
>Loop count: 4, Loop time: 355521106 ms
>rt_mutex_acquire 0
>Loop count: 5, Loop time: 355521107 ms
>rt_mutex_acquire 0
>Loop count: 6, Loop time: 355521108 ms
>rt_mutex_acquire 0
>Loop count: 7, Loop time: 355521109 ms
>rt_mutex_acquire 0
>Loop count: 8, Loop time: 355521110 ms
>rt_mutex_acquire 0
>
>
>void loop_task_proc(void *arg) {
>
>        int cnt = 0;
>        int ret = 0 ;
>
>        RTIME tstart1;
>
>        RT_MUTEX            m_tMutex;
>//      RT_SEM              m_tSemaphore;
>        ret = rt_mutex_create(&m_tMutex, "test");
>        rt_printf("rt_mutex_create %d\n", ret ) ;
>
>//      ret = rt_sem_create(&m_tSemaphore, "test", 1, S_FIFO);
>//      rt_printf("rt_sem_create %d\n", ret ) ;
>
>        //Print the info
>        rt_printf("task info \n");
>
>        rt_task_set_periodic(NULL, TM_NOW, LOOP_PERIOD);
>
>
>        //Start the task loop
>        while (1) {
>        ret =   rt_mutex_acquire(&m_tMutex, TM_INFINITE );
>        rt_printf("rt_mutex_acquire %d\n", ret ) ;
>
>//      rt_sem_p(&m_tSemaphore, TM_INFINITE ) ;
>//      rt_printf("rt_sem_p %d\n", ret ) ;
>//
>        tstart1 = rt_timer_read () ;
>        rt_printf("Loop count: %d, Loop time: %llu ms\n", cnt, tstart1 / 1000000 );
>        cnt++;
>        rt_task_wait_period(NULL);
>
>//      ret =           rt_mutex_release(&m_tMutex);
>//      rt_printf("rt_mutex_release %d\n", ret ) ;
>//      rt_sem_v(&m_tSemaphore);
>//      rt_printf("rt_sem_v %d\n", ret ) ;
>        }
>}
>
>int main(int argc, char* argv[])
>{
>
>        RT_TASK loop_task;
>        rt_task_create(&loop_task, "basicmath_small", 0, 50, 0);
>        rt_task_start(&loop_task, &loop_task_proc, 0);
>        //Wait for Ctrl-C
>        pause();
>        return 0;
>
>
>}
>
>Thanks.
>
>-----Original Message-----
>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>Sent: Wednesday, October 26, 2022 11:43 AM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원 두산로보틱스
><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스
><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스
><sangjoon.kim@doosan.com>; 김동주(Dongjoo
>Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>I have a basic question.
>
>If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI Processor
>CONFIG, We can't check the current cpu freq by sysnode.
>
>Because, sysnode of cpu freq is related to CPU_FREQ CONFIG and ACPI
>Processor CONFIG as i know.
>
>
>If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI Processor
>CONFIG, Could you expect the current cpu freq in the intel hw system ?
>
>Actually, The minimum cpu clock of our hw system is very low.
>
>If our hw system operate with minimum cpu clock always, I worry about
>the performance of hw system.
>
>
>sys/devices/system/cpu/cpu0/cpufreq# ls
>affected_cpus  cpuinfo_cur_freq  cpuinfo_min_freq            freqdomain_cpus
>scaling_available_frequencies  scaling_cur_freq  scaling_governor
>scaling_min_freq  stats
>bios_limit     cpuinfo_max_freq  cpuinfo_transition_latency  related_cpus
>scaling_available_governors    scaling_driver    scaling_max_freq
>scaling_setspeed
>
>
>Thanks.
>
>-----Original Message-----
>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>Sent: Tuesday, October 25, 2022 5:24 PM
>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원 두산로보틱스
><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스
><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스
><sangjoon.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시 주의하시기 바랍니다.
>
>CAUTION: This email is sent by an external account. Please take extra
>caution when clicking the link or opening the attachment.
>
>>-----Original Message-----
>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>
>>Sent: Tuesday, October 25, 2022 3:29 PM
>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>두산로보틱스
>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>두산로보틱스
>><dongjoo5.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스
>><youngjae7.lee@doosan.com>; 김상준(Sangjoon
>>Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>Dear Xenomai.org, Chen, Hongzhan
>>
>>I'm dong joo.
>>
>>After we do a aging test as like latency, We get a system hang about
>>ten hours later.
>>
>>At that time, Our system don't detect usb mouse.
>>
>>After rebooting our system by force,
>>there is no significative log in the kernel log or syslog.
>>
>>Could you help to us how to solve this issue ?
>
>Just as mentioned as in https://secure-
>web.cisco.com/1ll9UQp4RYnYXuVMxAlJKaDxV1RdMZtBcG3e_jDi4TlIxDMTzFM
>tJguJhndpS2BnNhGoAWwBP-G2UCWlarucvId1iz_ea_AU-
>U__8Gq6ZgF285KW8SRPHKr7NeWgE4dKG8o8PGMNJ3-
>lAB4xdptdPAk1vfJe8AL_Tt6oCEoT0OAr4RrSIjzqtmugt8EHD-
>jvxghKHjaWu1eGDkzOYtKpcV8WhZnz1wLItIZdChYT1xlXsFTU7-
>GnJhN2jLvMMlZgkMxzQLejJ2aB1wogBTkBIipva21mNGaSFb_sSZhX9ycwiT7UM
>UfQg5lyHCPZPEeP6/https%3A%2F%2Fxenomai.org%2Fpipermail%2Fxenomai%
>2F2022-April%2F047495.html
>1. It is highly recommended to use a UART as kernel debug output.
>2. enable CONFIG_XENO_OPT_WATCHDOG for xenomai, system will be able to
>tell RT application "hangs" (infinite loop at high prio) apart from
>real hangs/crashes.
>
>Regards
>
>Hongzhan Chen
>>
>>
>>We set up our system as like below sw.
>>
>>1. Xubuntu 18.04 LTS 32bit
>>
>>2. Linux kernel 4.1.18 32bit
>>
>>3. Xenomai 3.0.8 32bit
>>
>>4. Kernel config
>>   We refer to the xenomai page as like below.
>>
>>https://secure-
>web.cisco.com/1nAW3bSL64gGRUPlQWKtShagcypkiReyVX7nhG1T-J
>>upEWaqU-3hnCSt542V_mEwX-
>_8HsjCaWtSuQnJ3056Yq52DypR5psiqKgrOSq6pbk6xe-tw
>>xYZhwwm0akkU4iVwFscbrRTWdk2Ul-
>9fU2HilSTJ8rzI8X9LIfFg2foor5t9LawggXyjgq3
>>QqwJktjRWEhqL8gFDP2PpsmxrTgVK6NzJdcBxzyOGo_jmjjiO009l74YL2U5Ke3A
>7kc1AX7
>>IV_t016CRGEK4QyAKRuSTqKzFm8t4flDV7eBT4m43w-o_SoFrKq-
>AA7ZIKEYPEgpqq/http
>>s%3A%2F%2Fsource.denx.de%2FXenomai%2Fxenomai%2F-
>>/wikis/Configuring_For_X86_Based_Dual_Kernels#user-content-x86-
>>processor-type
>>
>>Thanks.
>>
>>-----Original Message-----
>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>Sent: Friday, August 26, 2022 2:40 PM
>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>두산로보틱스
>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>주의하시기 바랍니다.
>>
>>CAUTION: This email is sent by an external account. Please take extra
>>caution when clicking the link or opening the attachment.
>>
>>>-----Original Message-----
>>>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>>>Sent: Friday, August 26, 2022 10:41 AM
>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>>Cc: ???(Youngchul Park) ????? ??????
>><youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ??????
>><kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ??????
>><sehyun2.kim@doosan.com>; ???(Dongjoo Kim) ????? ??????
>><dongjoo5.kim@doosan.com>
>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>
>>>Dear Xenomai.org, Chen, Hongzhan
>>>
>>>I'm dong joo.
>>>
>>>Thank you for your reply to us our questions.
>>>
>>>And, We have checked the value of TICK_NSEC int our system.
>>>
>>>#define TICK_NSEC ((NSEC_PER_SEC+HZ/2)/HZ)
>>>#define NSEC_PER_SEC   1000000000L
>>>HZ  250 ( Max 1000 )
>>>
>>>The value of TICK_NSEC is defined by linux kernel.
>>>And, Both NSEC_PER_SEC and HZ calculate the value of TICK_NSEC.
>>>
>>>So, The current value of TICK_NSEC is 4ms based on 250 HZ.
>>>And, If we change the value of HZ to 1000, The value of TICK_NSEC may
>>>be
>>1ms.
>>>
>>>
>>>We hope to process a task every 20us using rt_task_yield as like
>>>Xenomai
>>2.6.5.
>>>
>>>Is there any method to achieve 20us task delay using rt_task_yield or
>>>another
>>xenomai method ?
>>>And, Is there any problem to reduce the delay more less than TICK_NSEC ?
>>
>>I just went through the implementation of rt_task_yield of Xeomai
>>2.6.5 and found that it is totally different from Xenomai 3.0.8.
>>If you want to yield about 20us for current RT thread ,you may try
>>call clock_nanosleep .
>>.
>>Regards
>>
>>Hongzhan Chen
>>>
>>>
>>>Really Thanks.
>>>
>>
>>
>>This e-mail and any attachments herein may contain confidential or
>>privileged information and is for the exclusive use of the intended
>>recipient(s) named above. If you are not the intended recipient(s),
>>you should not disseminate, distribute, retain, copy or otherwise use
>>any information contained herein. If you have received this e-mail in
>>error, please notify the sender immediately by replying to this
>>message and
>delete this e-mail and associated attachments.
>>Our company does not guarantee this e-mail is secure or free from viruses.
>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를
>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>
>
>This e-mail and any attachments herein may contain confidential or
>privileged information and is for the exclusive use of the intended
>recipient(s) named above. If you are not the intended recipient(s), you
>should not disseminate, distribute, retain, copy or otherwise use any
>information contained herein. If you have received this e-mail in
>error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments.
>Our company does not guarantee this e-mail is secure or free from viruses.
>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한
>수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.


This e-mail and any attachments herein may contain confidential or privileged information and is for the exclusive use of the intended recipient(s) named above. If you are not the intended recipient(s), you should not disseminate, distribute, retain, copy or otherwise use any information contained herein. If you have received this e-mail in error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments. Our company does not guarantee this e-mail is secure or free from viruses.
이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[Chen, Hongzhan]

>-----Original Message-----
>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Sent: Thursday, January 5, 2023 3:18 PM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim)
>수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>; 이형석(Hyungseok
>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song) 책임연구원 두산로보틱스
><changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원
>두산로보틱스 <kyungchan.son@doosan.com>; 김동주(Dongjoo Kim)
>책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>Thanks for your support.
>
>I have one more questions.
>
>Is the posix-mutex realtime mutex or not ?

Yes, it is realtime.

>
>And, Is there no problem to use the posix-mutex in the realtime Task ?

No, I do not think there is problem to use posix-mutex in realttime task. You can see that posix mutex  test already be covered in each release as one of smokey test.

>
>
>Finally, Is there any problem to use the rt_mutex_lock based on Xenomai
>guide?

From Xenomai 3 , all alchemy APIs such as rt_mutex_* actually is based on posix API, which is quite different from Xenomai 2.  

Regards

Hongzhan Chen
>
>
>Thanks.
>
>-----Original Message-----
>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>Sent: Thursday, January 5, 2023 4:03 PM
>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim)
>수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>; 이형석(Hyungseok
>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song) 책임연구원 두산로보틱스
><changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원
>두산로보틱스 <kyungchan.son@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>주의하시기 바랍니다.
>
>CAUTION: This email is sent by an external account. Please take extra caution
>when clicking the link or opening the attachment.
>
>Hi
>
>Why do not you use posix mutex like example in testsuite/smokey/posix-
>mutex/posix-mutex.c?
>
>
>Regards
>
>Hongzhan Chen
>
>>-----Original Message-----
>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>
>>Sent: Thursday, January 5, 2023 9:21 AM
>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스
>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>두산로보틱스
>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song) 책임연구원
>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>선임연구원 두산로보틱스
>><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>두산로보틱스
>><dongjoo5.kim@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>Dear Xenomai.org, Chen, Hongzhan
>>
>>I'm dong joo.
>>
>>Could you help me to solve this problem ?
>>
>>Thanks.
>>
>>-----Original Message-----
>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>
>>Sent: Monday, January 2, 2023 12:10 PM
>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스
>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>두산로보틱스
>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song) 책임연구원
>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>선임연구원 두산로보틱스
>><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>두산로보틱스
>><dongjoo5.kim@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>Dear Xenomai.org, Chen, Hongzhan
>>
>>I'm dong joo.
>>
>>We have tested the API of Xenomai rt_mutex as like rt_mutex_create,
>>rt_mutex_acquire, rt_mutex_release.
>>
>>
>>If we block the rt_mutex_release,
>>The next sequence can't get a rt_mutex_acquire by the previous sequence
>>don't call rt_mutex_release before.
>>
>>So, The result of count must be 0 what we think.
>>
>>But, The result of count increase abnormally as like below. Is there
>>any problem about rt_mutex_acquire or rt_mutex_release ?
>>
>>
>>If we test the API of Xenomai rt_sem as like rt_sem_create, rt_sem_p,
>>rt_sem_v, The result of count is 0.
>>
>>
>>rt_mutex_create 0
>>task info
>>rt_mutex_acquire 0
>>Loop count: 0, Loop time: 355521102 ms
>>rt_mutex_acquire 0
>>Loop count: 1, Loop time: 355521103 ms
>>rt_mutex_acquire 0
>>Loop count: 2, Loop time: 355521104 ms
>>rt_mutex_acquire 0
>>Loop count: 3, Loop time: 355521105 ms
>>rt_mutex_acquire 0
>>Loop count: 4, Loop time: 355521106 ms
>>rt_mutex_acquire 0
>>Loop count: 5, Loop time: 355521107 ms
>>rt_mutex_acquire 0
>>Loop count: 6, Loop time: 355521108 ms
>>rt_mutex_acquire 0
>>Loop count: 7, Loop time: 355521109 ms
>>rt_mutex_acquire 0
>>Loop count: 8, Loop time: 355521110 ms
>>rt_mutex_acquire 0
>>
>>
>>void loop_task_proc(void *arg) {
>>
>>        int cnt = 0;
>>        int ret = 0 ;
>>
>>        RTIME tstart1;
>>
>>        RT_MUTEX            m_tMutex;
>>//      RT_SEM              m_tSemaphore;
>>        ret = rt_mutex_create(&m_tMutex, "test");
>>        rt_printf("rt_mutex_create %d\n", ret ) ;
>>
>>//      ret = rt_sem_create(&m_tSemaphore, "test", 1, S_FIFO);
>>//      rt_printf("rt_sem_create %d\n", ret ) ;
>>
>>        //Print the info
>>        rt_printf("task info \n");
>>
>>        rt_task_set_periodic(NULL, TM_NOW, LOOP_PERIOD);
>>
>>
>>        //Start the task loop
>>        while (1) {
>>        ret =   rt_mutex_acquire(&m_tMutex, TM_INFINITE );
>>        rt_printf("rt_mutex_acquire %d\n", ret ) ;
>>
>>//      rt_sem_p(&m_tSemaphore, TM_INFINITE ) ;
>>//      rt_printf("rt_sem_p %d\n", ret ) ;
>>//
>>        tstart1 = rt_timer_read () ;
>>        rt_printf("Loop count: %d, Loop time: %llu ms\n", cnt, tstart1 /
>1000000 );
>>        cnt++;
>>        rt_task_wait_period(NULL);
>>
>>//      ret =           rt_mutex_release(&m_tMutex);
>>//      rt_printf("rt_mutex_release %d\n", ret ) ;
>>//      rt_sem_v(&m_tSemaphore);
>>//      rt_printf("rt_sem_v %d\n", ret ) ;
>>        }
>>}
>>
>>int main(int argc, char* argv[])
>>{
>>
>>        RT_TASK loop_task;
>>        rt_task_create(&loop_task, "basicmath_small", 0, 50, 0);
>>        rt_task_start(&loop_task, &loop_task_proc, 0);
>>        //Wait for Ctrl-C
>>        pause();
>>        return 0;
>>
>>
>>}
>>
>>Thanks.
>>
>>-----Original Message-----
>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>Sent: Wednesday, October 26, 2022 11:43 AM
>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>두산로보틱스
>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스
>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>두산로보틱스
>><sangjoon.kim@doosan.com>; 김동주(Dongjoo
>>Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>Dear Xenomai.org, Chen, Hongzhan
>>
>>I'm dong joo.
>>
>>I have a basic question.
>>
>>If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI Processor
>>CONFIG, We can't check the current cpu freq by sysnode.
>>
>>Because, sysnode of cpu freq is related to CPU_FREQ CONFIG and ACPI
>>Processor CONFIG as i know.
>>
>>
>>If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI Processor
>>CONFIG, Could you expect the current cpu freq in the intel hw system ?
>>
>>Actually, The minimum cpu clock of our hw system is very low.
>>
>>If our hw system operate with minimum cpu clock always, I worry about
>>the performance of hw system.
>>
>>
>>sys/devices/system/cpu/cpu0/cpufreq# ls
>>affected_cpus  cpuinfo_cur_freq  cpuinfo_min_freq            freqdomain_cpus
>>scaling_available_frequencies  scaling_cur_freq  scaling_governor
>>scaling_min_freq  stats
>>bios_limit     cpuinfo_max_freq  cpuinfo_transition_latency  related_cpus
>>scaling_available_governors    scaling_driver    scaling_max_freq
>>scaling_setspeed
>>
>>
>>Thanks.
>>
>>-----Original Message-----
>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>Sent: Tuesday, October 25, 2022 5:24 PM
>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>두산로보틱스
>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스
>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>두산로보틱스
>><sangjoon.kim@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>주의하시기 바랍니다.
>>
>>CAUTION: This email is sent by an external account. Please take extra
>>caution when clicking the link or opening the attachment.
>>
>>>-----Original Message-----
>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>><dongjoo5.kim@doosan.com>
>>>Sent: Tuesday, October 25, 2022 3:29 PM
>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>>두산로보틱스
>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>두산로보틱스
>>><sehyun2.kim@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>두산로보틱스
>>><dongjoo5.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>두산로보틱스
>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon
>>>Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>
>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>
>>>Dear Xenomai.org, Chen, Hongzhan
>>>
>>>I'm dong joo.
>>>
>>>After we do a aging test as like latency, We get a system hang about
>>>ten hours later.
>>>
>>>At that time, Our system don't detect usb mouse.
>>>
>>>After rebooting our system by force,
>>>there is no significative log in the kernel log or syslog.
>>>
>>>Could you help to us how to solve this issue ?
>>
>>Just as mentioned as in https://secure-
>>web.cisco.com/1ll9UQp4RYnYXuVMxAlJKaDxV1RdMZtBcG3e_jDi4TlIxDMTzF
>M
>>tJguJhndpS2BnNhGoAWwBP-G2UCWlarucvId1iz_ea_AU-
>>U__8Gq6ZgF285KW8SRPHKr7NeWgE4dKG8o8PGMNJ3-
>>lAB4xdptdPAk1vfJe8AL_Tt6oCEoT0OAr4RrSIjzqtmugt8EHD-
>>jvxghKHjaWu1eGDkzOYtKpcV8WhZnz1wLItIZdChYT1xlXsFTU7-
>>GnJhN2jLvMMlZgkMxzQLejJ2aB1wogBTkBIipva21mNGaSFb_sSZhX9ycwiT7UM
>>UfQg5lyHCPZPEeP6/https%3A%2F%2Fxenomai.org%2Fpipermail%2Fxenomai%
>>2F2022-April%2F047495.html
>>1. It is highly recommended to use a UART as kernel debug output.
>>2. enable CONFIG_XENO_OPT_WATCHDOG for xenomai, system will be able
>to
>>tell RT application "hangs" (infinite loop at high prio) apart from
>>real hangs/crashes.
>>
>>Regards
>>
>>Hongzhan Chen
>>>
>>>
>>>We set up our system as like below sw.
>>>
>>>1. Xubuntu 18.04 LTS 32bit
>>>
>>>2. Linux kernel 4.1.18 32bit
>>>
>>>3. Xenomai 3.0.8 32bit
>>>
>>>4. Kernel config
>>>   We refer to the xenomai page as like below.
>>>
>>>https://secure-
>>web.cisco.com/1nAW3bSL64gGRUPlQWKtShagcypkiReyVX7nhG1T-J
>>>upEWaqU-3hnCSt542V_mEwX-
>>_8HsjCaWtSuQnJ3056Yq52DypR5psiqKgrOSq6pbk6xe-tw
>>>xYZhwwm0akkU4iVwFscbrRTWdk2Ul-
>>9fU2HilSTJ8rzI8X9LIfFg2foor5t9LawggXyjgq3
>>>QqwJktjRWEhqL8gFDP2PpsmxrTgVK6NzJdcBxzyOGo_jmjjiO009l74YL2U5Ke3
>A
>>7kc1AX7
>>>IV_t016CRGEK4QyAKRuSTqKzFm8t4flDV7eBT4m43w-o_SoFrKq-
>>AA7ZIKEYPEgpqq/http
>>>s%3A%2F%2Fsource.denx.de%2FXenomai%2Fxenomai%2F-
>>>/wikis/Configuring_For_X86_Based_Dual_Kernels#user-content-x86-
>>>processor-type
>>>
>>>Thanks.
>>>
>>>-----Original Message-----
>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>Sent: Friday, August 26, 2022 2:40 PM
>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>>두산로보틱스
>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>두산로보틱스
>>><sehyun2.kim@doosan.com>
>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>
>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>>주의하시기 바랍니다.
>>>
>>>CAUTION: This email is sent by an external account. Please take extra
>>>caution when clicking the link or opening the attachment.
>>>
>>>>-----Original Message-----
>>>>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>>>>Sent: Friday, August 26, 2022 10:41 AM
>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>>>Cc: ???(Youngchul Park) ????? ??????
>>><youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ??????
>>><kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ??????
>>><sehyun2.kim@doosan.com>; ???(Dongjoo Kim) ????? ??????
>>><dongjoo5.kim@doosan.com>
>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>
>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>
>>>>I'm dong joo.
>>>>
>>>>Thank you for your reply to us our questions.
>>>>
>>>>And, We have checked the value of TICK_NSEC int our system.
>>>>
>>>>#define TICK_NSEC ((NSEC_PER_SEC+HZ/2)/HZ)
>>>>#define NSEC_PER_SEC   1000000000L
>>>>HZ  250 ( Max 1000 )
>>>>
>>>>The value of TICK_NSEC is defined by linux kernel.
>>>>And, Both NSEC_PER_SEC and HZ calculate the value of TICK_NSEC.
>>>>
>>>>So, The current value of TICK_NSEC is 4ms based on 250 HZ.
>>>>And, If we change the value of HZ to 1000, The value of TICK_NSEC may
>>>>be
>>>1ms.
>>>>
>>>>
>>>>We hope to process a task every 20us using rt_task_yield as like
>>>>Xenomai
>>>2.6.5.
>>>>
>>>>Is there any method to achieve 20us task delay using rt_task_yield or
>>>>another
>>>xenomai method ?
>>>>And, Is there any problem to reduce the delay more less than TICK_NSEC ?
>>>
>>>I just went through the implementation of rt_task_yield of Xeomai
>>>2.6.5 and found that it is totally different from Xenomai 3.0.8.
>>>If you want to yield about 20us for current RT thread ,you may try
>>>call clock_nanosleep .
>>>.
>>>Regards
>>>
>>>Hongzhan Chen
>>>>
>>>>
>>>>Really Thanks.
>>>>
>>>
>>>
>>>This e-mail and any attachments herein may contain confidential or
>>>privileged information and is for the exclusive use of the intended
>>>recipient(s) named above. If you are not the intended recipient(s),
>>>you should not disseminate, distribute, retain, copy or otherwise use
>>>any information contained herein. If you have received this e-mail in
>>>error, please notify the sender immediately by replying to this
>>>message and
>>delete this e-mail and associated attachments.
>>>Our company does not guarantee this e-mail is secure or free from viruses.
>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>용도로도 이를
>>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>>
>>
>>This e-mail and any attachments herein may contain confidential or
>>privileged information and is for the exclusive use of the intended
>>recipient(s) named above. If you are not the intended recipient(s), you
>>should not disseminate, distribute, retain, copy or otherwise use any
>>information contained herein. If you have received this e-mail in
>>error, please notify the sender immediately by replying to this message and
>delete this e-mail and associated attachments.
>>Our company does not guarantee this e-mail is secure or free from viruses.
>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한
>>수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를
>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>
>
>This e-mail and any attachments herein may contain confidential or privileged
>information and is for the exclusive use of the intended recipient(s) named
>above. If you are not the intended recipient(s), you should not disseminate,
>distribute, retain, copy or otherwise use any information contained herein. If
>you have received this e-mail in error, please notify the sender immediately by
>replying to this message and delete this e-mail and associated attachments.
>Our company does not guarantee this e-mail is secure or free from viruses.
>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한
>수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를
>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에
>관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신
>경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기
>바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[Chen, Hongzhan]

>-----Original Message-----
>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>Sent: Thursday, January 5, 2023 5:25 PM
>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim)
>수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>; 이형석(Hyungseok
>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song) 책임연구원 두산로보틱스
><changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원
>두산로보틱스 <kyungchan.son@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>
>
>>-----Original Message-----
>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>
>>Sent: Thursday, January 5, 2023 3:18 PM
>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim)
>>수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>;
>이형석(Hyungseok
>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>송창우(Changwoo Song) 책임연구원 두산로보틱스
>><changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원
>>두산로보틱스 <kyungchan.son@doosan.com>; 김동주(Dongjoo Kim)
>>책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>Dear Xenomai.org, Chen, Hongzhan
>>
>>I'm dong joo.
>>
>>Thanks for your support.
>>
>>I have one more questions.
>>
>>Is the posix-mutex realtime mutex or not ?
>
>Yes, it is realtime.
>
>>
>>And, Is there no problem to use the posix-mutex in the realtime Task ?
>
>No, I do not think there is problem to use posix-mutex in realttime task. You
>can see that posix mutex  test already be covered in each release as one of
>smokey test.
>
>>
>>
>>Finally, Is there any problem to use the rt_mutex_lock based on Xenomai
>>guide?
>
>From Xenomai 3 , all alchemy APIs such as rt_mutex_* actually is based on
>posix API, which is quite different from Xenomai 2.

According to doc/asciidoc/MIGRATION.adoc,

- Like +rt_mutex_inquire()+, +rt_cond_inquire()+ does not return the
count of waiting tasks anymore.

Regards

Hongzhan Chen
>
>Regards
>
>Hongzhan Chen
>>
>>
>>Thanks.
>>
>>-----Original Message-----
>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>Sent: Thursday, January 5, 2023 4:03 PM
>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim)
>>수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>;
>이형석(Hyungseok
>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>송창우(Changwoo Song) 책임연구원 두산로보틱스
>><changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원
>>두산로보틱스 <kyungchan.son@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>>주의하시기 바랍니다.
>>
>>CAUTION: This email is sent by an external account. Please take extra caution
>>when clicking the link or opening the attachment.
>>
>>Hi
>>
>>Why do not you use posix mutex like example in testsuite/smokey/posix-
>>mutex/posix-mutex.c?
>>
>>
>>Regards
>>
>>Hongzhan Chen
>>
>>>-----Original Message-----
>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>><dongjoo5.kim@doosan.com>
>>>Sent: Thursday, January 5, 2023 9:21 AM
>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>두산로보틱스
>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>두산로보틱스
>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>두산로보틱스
>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>송창우(Changwoo Song) 책임연구원
>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>>선임연구원 두산로보틱스
>>><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>두산로보틱스
>>><dongjoo5.kim@doosan.com>
>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>
>>>Dear Xenomai.org, Chen, Hongzhan
>>>
>>>I'm dong joo.
>>>
>>>Could you help me to solve this problem ?
>>>
>>>Thanks.
>>>
>>>-----Original Message-----
>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>><dongjoo5.kim@doosan.com>
>>>Sent: Monday, January 2, 2023 12:10 PM
>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>두산로보틱스
>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>두산로보틱스
>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>두산로보틱스
>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>송창우(Changwoo Song) 책임연구원
>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>>선임연구원 두산로보틱스
>>><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>두산로보틱스
>>><dongjoo5.kim@doosan.com>
>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>
>>>Dear Xenomai.org, Chen, Hongzhan
>>>
>>>I'm dong joo.
>>>
>>>We have tested the API of Xenomai rt_mutex as like rt_mutex_create,
>>>rt_mutex_acquire, rt_mutex_release.
>>>
>>>
>>>If we block the rt_mutex_release,
>>>The next sequence can't get a rt_mutex_acquire by the previous sequence
>>>don't call rt_mutex_release before.
>>>
>>>So, The result of count must be 0 what we think.
>>>
>>>But, The result of count increase abnormally as like below. Is there
>>>any problem about rt_mutex_acquire or rt_mutex_release ?
>>>
>>>
>>>If we test the API of Xenomai rt_sem as like rt_sem_create, rt_sem_p,
>>>rt_sem_v, The result of count is 0.
>>>
>>>
>>>rt_mutex_create 0
>>>task info
>>>rt_mutex_acquire 0
>>>Loop count: 0, Loop time: 355521102 ms
>>>rt_mutex_acquire 0
>>>Loop count: 1, Loop time: 355521103 ms
>>>rt_mutex_acquire 0
>>>Loop count: 2, Loop time: 355521104 ms
>>>rt_mutex_acquire 0
>>>Loop count: 3, Loop time: 355521105 ms
>>>rt_mutex_acquire 0
>>>Loop count: 4, Loop time: 355521106 ms
>>>rt_mutex_acquire 0
>>>Loop count: 5, Loop time: 355521107 ms
>>>rt_mutex_acquire 0
>>>Loop count: 6, Loop time: 355521108 ms
>>>rt_mutex_acquire 0
>>>Loop count: 7, Loop time: 355521109 ms
>>>rt_mutex_acquire 0
>>>Loop count: 8, Loop time: 355521110 ms
>>>rt_mutex_acquire 0
>>>
>>>
>>>void loop_task_proc(void *arg) {
>>>
>>>        int cnt = 0;
>>>        int ret = 0 ;
>>>
>>>        RTIME tstart1;
>>>
>>>        RT_MUTEX            m_tMutex;
>>>//      RT_SEM              m_tSemaphore;
>>>        ret = rt_mutex_create(&m_tMutex, "test");
>>>        rt_printf("rt_mutex_create %d\n", ret ) ;
>>>
>>>//      ret = rt_sem_create(&m_tSemaphore, "test", 1, S_FIFO);
>>>//      rt_printf("rt_sem_create %d\n", ret ) ;
>>>
>>>        //Print the info
>>>        rt_printf("task info \n");
>>>
>>>        rt_task_set_periodic(NULL, TM_NOW, LOOP_PERIOD);
>>>
>>>
>>>        //Start the task loop
>>>        while (1) {
>>>        ret =   rt_mutex_acquire(&m_tMutex, TM_INFINITE );
>>>        rt_printf("rt_mutex_acquire %d\n", ret ) ;
>>>
>>>//      rt_sem_p(&m_tSemaphore, TM_INFINITE ) ;
>>>//      rt_printf("rt_sem_p %d\n", ret ) ;
>>>//
>>>        tstart1 = rt_timer_read () ;
>>>        rt_printf("Loop count: %d, Loop time: %llu ms\n", cnt, tstart1 /
>>1000000 );
>>>        cnt++;
>>>        rt_task_wait_period(NULL);
>>>
>>>//      ret =           rt_mutex_release(&m_tMutex);
>>>//      rt_printf("rt_mutex_release %d\n", ret ) ;
>>>//      rt_sem_v(&m_tSemaphore);
>>>//      rt_printf("rt_sem_v %d\n", ret ) ;
>>>        }
>>>}
>>>
>>>int main(int argc, char* argv[])
>>>{
>>>
>>>        RT_TASK loop_task;
>>>        rt_task_create(&loop_task, "basicmath_small", 0, 50, 0);
>>>        rt_task_start(&loop_task, &loop_task_proc, 0);
>>>        //Wait for Ctrl-C
>>>        pause();
>>>        return 0;
>>>
>>>
>>>}
>>>
>>>Thanks.
>>>
>>>-----Original Message-----
>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>Sent: Wednesday, October 26, 2022 11:43 AM
>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>>두산로보틱스
>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>두산로보틱스
>>><sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>두산로보틱스
>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>두산로보틱스
>>><sangjoon.kim@doosan.com>; 김동주(Dongjoo
>>>Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>
>>>Dear Xenomai.org, Chen, Hongzhan
>>>
>>>I'm dong joo.
>>>
>>>I have a basic question.
>>>
>>>If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI Processor
>>>CONFIG, We can't check the current cpu freq by sysnode.
>>>
>>>Because, sysnode of cpu freq is related to CPU_FREQ CONFIG and ACPI
>>>Processor CONFIG as i know.
>>>
>>>
>>>If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI Processor
>>>CONFIG, Could you expect the current cpu freq in the intel hw system ?
>>>
>>>Actually, The minimum cpu clock of our hw system is very low.
>>>
>>>If our hw system operate with minimum cpu clock always, I worry about
>>>the performance of hw system.
>>>
>>>
>>>sys/devices/system/cpu/cpu0/cpufreq# ls
>>>affected_cpus  cpuinfo_cur_freq  cpuinfo_min_freq            freqdomain_cpus
>>>scaling_available_frequencies  scaling_cur_freq  scaling_governor
>>>scaling_min_freq  stats
>>>bios_limit     cpuinfo_max_freq  cpuinfo_transition_latency  related_cpus
>>>scaling_available_governors    scaling_driver    scaling_max_freq
>>>scaling_setspeed
>>>
>>>
>>>Thanks.
>>>
>>>-----Original Message-----
>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>Sent: Tuesday, October 25, 2022 5:24 PM
>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>>두산로보틱스
>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>두산로보틱스
>>><sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>두산로보틱스
>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>두산로보틱스
>>><sangjoon.kim@doosan.com>
>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>
>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>>주의하시기 바랍니다.
>>>
>>>CAUTION: This email is sent by an external account. Please take extra
>>>caution when clicking the link or opening the attachment.
>>>
>>>>-----Original Message-----
>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>><dongjoo5.kim@doosan.com>
>>>>Sent: Tuesday, October 25, 2022 3:29 PM
>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>>><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>>>두산로보틱스
>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>두산로보틱스
>>>><sehyun2.kim@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>>두산로보틱스
>>>><dongjoo5.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>두산로보틱스
>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon
>>>>Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>
>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>
>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>
>>>>I'm dong joo.
>>>>
>>>>After we do a aging test as like latency, We get a system hang about
>>>>ten hours later.
>>>>
>>>>At that time, Our system don't detect usb mouse.
>>>>
>>>>After rebooting our system by force,
>>>>there is no significative log in the kernel log or syslog.
>>>>
>>>>Could you help to us how to solve this issue ?
>>>
>>>Just as mentioned as in https://secure-
>>>web.cisco.com/1ll9UQp4RYnYXuVMxAlJKaDxV1RdMZtBcG3e_jDi4TlIxDMTzF
>>M
>>>tJguJhndpS2BnNhGoAWwBP-G2UCWlarucvId1iz_ea_AU-
>>>U__8Gq6ZgF285KW8SRPHKr7NeWgE4dKG8o8PGMNJ3-
>>>lAB4xdptdPAk1vfJe8AL_Tt6oCEoT0OAr4RrSIjzqtmugt8EHD-
>>>jvxghKHjaWu1eGDkzOYtKpcV8WhZnz1wLItIZdChYT1xlXsFTU7-
>>>GnJhN2jLvMMlZgkMxzQLejJ2aB1wogBTkBIipva21mNGaSFb_sSZhX9ycwiT7U
>M
>>>UfQg5lyHCPZPEeP6/https%3A%2F%2Fxenomai.org%2Fpipermail%2Fxenom
>ai%
>>>2F2022-April%2F047495.html
>>>1. It is highly recommended to use a UART as kernel debug output.
>>>2. enable CONFIG_XENO_OPT_WATCHDOG for xenomai, system will be able
>>to
>>>tell RT application "hangs" (infinite loop at high prio) apart from
>>>real hangs/crashes.
>>>
>>>Regards
>>>
>>>Hongzhan Chen
>>>>
>>>>
>>>>We set up our system as like below sw.
>>>>
>>>>1. Xubuntu 18.04 LTS 32bit
>>>>
>>>>2. Linux kernel 4.1.18 32bit
>>>>
>>>>3. Xenomai 3.0.8 32bit
>>>>
>>>>4. Kernel config
>>>>   We refer to the xenomai page as like below.
>>>>
>>>>https://secure-
>>>web.cisco.com/1nAW3bSL64gGRUPlQWKtShagcypkiReyVX7nhG1T-J
>>>>upEWaqU-3hnCSt542V_mEwX-
>>>_8HsjCaWtSuQnJ3056Yq52DypR5psiqKgrOSq6pbk6xe-tw
>>>>xYZhwwm0akkU4iVwFscbrRTWdk2Ul-
>>>9fU2HilSTJ8rzI8X9LIfFg2foor5t9LawggXyjgq3
>>>>QqwJktjRWEhqL8gFDP2PpsmxrTgVK6NzJdcBxzyOGo_jmjjiO009l74YL2U5Ke
>3
>>A
>>>7kc1AX7
>>>>IV_t016CRGEK4QyAKRuSTqKzFm8t4flDV7eBT4m43w-o_SoFrKq-
>>>AA7ZIKEYPEgpqq/http
>>>>s%3A%2F%2Fsource.denx.de%2FXenomai%2Fxenomai%2F-
>>>>/wikis/Configuring_For_X86_Based_Dual_Kernels#user-content-x86-
>>>>processor-type
>>>>
>>>>Thanks.
>>>>
>>>>-----Original Message-----
>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>Sent: Friday, August 26, 2022 2:40 PM
>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>>><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>>>두산로보틱스
>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>두산로보틱스
>>>><sehyun2.kim@doosan.com>
>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>
>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>>>주의하시기 바랍니다.
>>>>
>>>>CAUTION: This email is sent by an external account. Please take extra
>>>>caution when clicking the link or opening the attachment.
>>>>
>>>>>-----Original Message-----
>>>>>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>>>>>Sent: Friday, August 26, 2022 10:41 AM
>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>xenomai@xenomai.org
>>>>>Cc: ???(Youngchul Park) ????? ??????
>>>><youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ??????
>>>><kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ??????
>>>><sehyun2.kim@doosan.com>; ???(Dongjoo Kim) ????? ??????
>>>><dongjoo5.kim@doosan.com>
>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>
>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>
>>>>>I'm dong joo.
>>>>>
>>>>>Thank you for your reply to us our questions.
>>>>>
>>>>>And, We have checked the value of TICK_NSEC int our system.
>>>>>
>>>>>#define TICK_NSEC ((NSEC_PER_SEC+HZ/2)/HZ)
>>>>>#define NSEC_PER_SEC   1000000000L
>>>>>HZ  250 ( Max 1000 )
>>>>>
>>>>>The value of TICK_NSEC is defined by linux kernel.
>>>>>And, Both NSEC_PER_SEC and HZ calculate the value of TICK_NSEC.
>>>>>
>>>>>So, The current value of TICK_NSEC is 4ms based on 250 HZ.
>>>>>And, If we change the value of HZ to 1000, The value of TICK_NSEC may
>>>>>be
>>>>1ms.
>>>>>
>>>>>
>>>>>We hope to process a task every 20us using rt_task_yield as like
>>>>>Xenomai
>>>>2.6.5.
>>>>>
>>>>>Is there any method to achieve 20us task delay using rt_task_yield or
>>>>>another
>>>>xenomai method ?
>>>>>And, Is there any problem to reduce the delay more less than TICK_NSEC ?
>>>>
>>>>I just went through the implementation of rt_task_yield of Xeomai
>>>>2.6.5 and found that it is totally different from Xenomai 3.0.8.
>>>>If you want to yield about 20us for current RT thread ,you may try
>>>>call clock_nanosleep .
>>>>.
>>>>Regards
>>>>
>>>>Hongzhan Chen
>>>>>
>>>>>
>>>>>Really Thanks.
>>>>>
>>>>
>>>>
>>>>This e-mail and any attachments herein may contain confidential or
>>>>privileged information and is for the exclusive use of the intended
>>>>recipient(s) named above. If you are not the intended recipient(s),
>>>>you should not disseminate, distribute, retain, copy or otherwise use
>>>>any information contained herein. If you have received this e-mail in
>>>>error, please notify the sender immediately by replying to this
>>>>message and
>>>delete this e-mail and associated attachments.
>>>>Our company does not guarantee this e-mail is secure or free from viruses.
>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>포함하고
>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>>용도로도 이를
>>>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>>>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>>>
>>>
>>>This e-mail and any attachments herein may contain confidential or
>>>privileged information and is for the exclusive use of the intended
>>>recipient(s) named above. If you are not the intended recipient(s), you
>>>should not disseminate, distribute, retain, copy or otherwise use any
>>>information contained herein. If you have received this e-mail in
>>>error, please notify the sender immediately by replying to this message and
>>delete this e-mail and associated attachments.
>>>Our company does not guarantee this e-mail is secure or free from viruses.
>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한
>>>수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를
>>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>>
>>
>>This e-mail and any attachments herein may contain confidential or
>privileged
>>information and is for the exclusive use of the intended recipient(s) named
>>above. If you are not the intended recipient(s), you should not disseminate,
>>distribute, retain, copy or otherwise use any information contained herein. If
>>you have received this e-mail in error, please notify the sender immediately
>by
>>replying to this message and delete this e-mail and associated attachments.
>>Our company does not guarantee this e-mail is secure or free from viruses.
>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한
>>수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를
>>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에
>>관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못
>수신하신
>>경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기
>>바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[김동주(Dongjoo Kim) 책임연구원 두산로보틱스]

Dear Xenomai.org, Chen, Hongzhan

I'm dong joo.

I'm really thanks for your support.


If we test a rt_mutex_create, rt_mutex_acquire, rt_mutex_release with Xenomai 2.6.5,
The test result is same to Xenomai 3.

Even though we disable rt_mutex_release API, the count increase increase abnormally.

Is the result normal case or not ?

Could you share to us the comment about the result ?

Thanks.
-----Original Message-----
From: Chen, Hongzhan <hongzhan.chen@intel.com>
Sent: Thursday, January 5, 2023 6:41 PM
To: Chen, Hongzhan <hongzhan.chen@intel.com>; 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>; xenomai@xenomai.org
Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스 <sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>; 이형석(Hyungseok Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>; 송창우(Changwoo Song) 책임연구원 두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원 두산로보틱스 <kyungchan.son@doosan.com>
Subject: RE: What causes the latency of the rt_task_yield() API?

주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시 주의하시기 바랍니다.

CAUTION: This email is sent by an external account. Please take extra caution when clicking the link or opening the attachment.

>-----Original Message-----
>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>Sent: Thursday, January 5, 2023 5:25 PM
>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스
><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스
><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>; 송창우(Changwoo Song) 책임연구원
>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원 두산로보틱스
><kyungchan.son@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>
>
>>-----Original Message-----
>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>
>>Sent: Thursday, January 5, 2023 3:18 PM
>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스
>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스
>><sangjoon.kim@doosan.com>;
>이형석(Hyungseok
>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>; 송창우(Changwoo Song)
>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원
>>두산로보틱스 <kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>Dear Xenomai.org, Chen, Hongzhan
>>
>>I'm dong joo.
>>
>>Thanks for your support.
>>
>>I have one more questions.
>>
>>Is the posix-mutex realtime mutex or not ?
>
>Yes, it is realtime.
>
>>
>>And, Is there no problem to use the posix-mutex in the realtime Task ?
>
>No, I do not think there is problem to use posix-mutex in realttime
>task. You can see that posix mutex  test already be covered in each
>release as one of smokey test.
>
>>
>>
>>Finally, Is there any problem to use the rt_mutex_lock based on
>>Xenomai guide?
>
>From Xenomai 3 , all alchemy APIs such as rt_mutex_* actually is based
>on posix API, which is quite different from Xenomai 2.

According to doc/asciidoc/MIGRATION.adoc,

- Like +rt_mutex_inquire()+, +rt_cond_inquire()+ does not return the count of waiting tasks anymore.

Regards

Hongzhan Chen
>
>Regards
>
>Hongzhan Chen
>>
>>
>>Thanks.
>>
>>-----Original Message-----
>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>Sent: Thursday, January 5, 2023 4:03 PM
>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스
>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스
>><sangjoon.kim@doosan.com>;
>이형석(Hyungseok
>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>; 송창우(Changwoo Song)
>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원
>>두산로보틱스 <kyungchan.son@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시 주의하시기 바랍니다.
>>
>>CAUTION: This email is sent by an external account. Please take extra
>>caution when clicking the link or opening the attachment.
>>
>>Hi
>>
>>Why do not you use posix mutex like example in testsuite/smokey/posix-
>>mutex/posix-mutex.c?
>>
>>
>>Regards
>>
>>Hongzhan Chen
>>
>>>-----Original Message-----
>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>><dongjoo5.kim@doosan.com>
>>>Sent: Thursday, January 5, 2023 9:21 AM
>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>두산로보틱스
>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>두산로보틱스
>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>두산로보틱스
>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>송창우(Changwoo Song) 책임연구원
>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>>선임연구원 두산로보틱스
>>><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>두산로보틱스
>>><dongjoo5.kim@doosan.com>
>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>
>>>Dear Xenomai.org, Chen, Hongzhan
>>>
>>>I'm dong joo.
>>>
>>>Could you help me to solve this problem ?
>>>
>>>Thanks.
>>>
>>>-----Original Message-----
>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>><dongjoo5.kim@doosan.com>
>>>Sent: Monday, January 2, 2023 12:10 PM
>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>두산로보틱스
>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>두산로보틱스
>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>두산로보틱스
>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>송창우(Changwoo Song) 책임연구원
>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>>선임연구원 두산로보틱스
>>><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>두산로보틱스
>>><dongjoo5.kim@doosan.com>
>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>
>>>Dear Xenomai.org, Chen, Hongzhan
>>>
>>>I'm dong joo.
>>>
>>>We have tested the API of Xenomai rt_mutex as like rt_mutex_create,
>>>rt_mutex_acquire, rt_mutex_release.
>>>
>>>
>>>If we block the rt_mutex_release,
>>>The next sequence can't get a rt_mutex_acquire by the previous
>>>sequence don't call rt_mutex_release before.
>>>
>>>So, The result of count must be 0 what we think.
>>>
>>>But, The result of count increase abnormally as like below. Is there
>>>any problem about rt_mutex_acquire or rt_mutex_release ?
>>>
>>>
>>>If we test the API of Xenomai rt_sem as like rt_sem_create, rt_sem_p,
>>>rt_sem_v, The result of count is 0.
>>>
>>>
>>>rt_mutex_create 0
>>>task info
>>>rt_mutex_acquire 0
>>>Loop count: 0, Loop time: 355521102 ms rt_mutex_acquire 0 Loop count:
>>>1, Loop time: 355521103 ms rt_mutex_acquire 0 Loop count: 2, Loop
>>>time: 355521104 ms rt_mutex_acquire 0 Loop count: 3, Loop time:
>>>355521105 ms rt_mutex_acquire 0 Loop count: 4, Loop time: 355521106
>>>ms rt_mutex_acquire 0 Loop count: 5, Loop time: 355521107 ms
>>>rt_mutex_acquire 0 Loop count: 6, Loop time: 355521108 ms
>>>rt_mutex_acquire 0 Loop count: 7, Loop time: 355521109 ms
>>>rt_mutex_acquire 0 Loop count: 8, Loop time: 355521110 ms
>>>rt_mutex_acquire 0
>>>
>>>
>>>void loop_task_proc(void *arg) {
>>>
>>>        int cnt = 0;
>>>        int ret = 0 ;
>>>
>>>        RTIME tstart1;
>>>
>>>        RT_MUTEX            m_tMutex;
>>>//      RT_SEM              m_tSemaphore;
>>>        ret = rt_mutex_create(&m_tMutex, "test");
>>>        rt_printf("rt_mutex_create %d\n", ret ) ;
>>>
>>>//      ret = rt_sem_create(&m_tSemaphore, "test", 1, S_FIFO);
>>>//      rt_printf("rt_sem_create %d\n", ret ) ;
>>>
>>>        //Print the info
>>>        rt_printf("task info \n");
>>>
>>>        rt_task_set_periodic(NULL, TM_NOW, LOOP_PERIOD);
>>>
>>>
>>>        //Start the task loop
>>>        while (1) {
>>>        ret =   rt_mutex_acquire(&m_tMutex, TM_INFINITE );
>>>        rt_printf("rt_mutex_acquire %d\n", ret ) ;
>>>
>>>//      rt_sem_p(&m_tSemaphore, TM_INFINITE ) ;
>>>//      rt_printf("rt_sem_p %d\n", ret ) ;
>>>//
>>>        tstart1 = rt_timer_read () ;
>>>        rt_printf("Loop count: %d, Loop time: %llu ms\n", cnt,
>>>tstart1 /
>>1000000 );
>>>        cnt++;
>>>        rt_task_wait_period(NULL);
>>>
>>>//      ret =           rt_mutex_release(&m_tMutex);
>>>//      rt_printf("rt_mutex_release %d\n", ret ) ;
>>>//      rt_sem_v(&m_tSemaphore);
>>>//      rt_printf("rt_sem_v %d\n", ret ) ;
>>>        }
>>>}
>>>
>>>int main(int argc, char* argv[])
>>>{
>>>
>>>        RT_TASK loop_task;
>>>        rt_task_create(&loop_task, "basicmath_small", 0, 50, 0);
>>>        rt_task_start(&loop_task, &loop_task_proc, 0);
>>>        //Wait for Ctrl-C
>>>        pause();
>>>        return 0;
>>>
>>>
>>>}
>>>
>>>Thanks.
>>>
>>>-----Original Message-----
>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>Sent: Wednesday, October 26, 2022 11:43 AM
>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>>두산로보틱스
>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>두산로보틱스
>>><sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>두산로보틱스
>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>두산로보틱스
>>><sangjoon.kim@doosan.com>; 김동주(Dongjoo
>>>Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>
>>>Dear Xenomai.org, Chen, Hongzhan
>>>
>>>I'm dong joo.
>>>
>>>I have a basic question.
>>>
>>>If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI Processor
>>>CONFIG, We can't check the current cpu freq by sysnode.
>>>
>>>Because, sysnode of cpu freq is related to CPU_FREQ CONFIG and ACPI
>>>Processor CONFIG as i know.
>>>
>>>
>>>If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI Processor
>>>CONFIG, Could you expect the current cpu freq in the intel hw system ?
>>>
>>>Actually, The minimum cpu clock of our hw system is very low.
>>>
>>>If our hw system operate with minimum cpu clock always, I worry about
>>>the performance of hw system.
>>>
>>>
>>>sys/devices/system/cpu/cpu0/cpufreq# ls
>>>affected_cpus  cpuinfo_cur_freq  cpuinfo_min_freq            freqdomain_cpus
>>>scaling_available_frequencies  scaling_cur_freq  scaling_governor
>>>scaling_min_freq  stats
>>>bios_limit     cpuinfo_max_freq  cpuinfo_transition_latency  related_cpus
>>>scaling_available_governors    scaling_driver    scaling_max_freq
>>>scaling_setspeed
>>>
>>>
>>>Thanks.
>>>
>>>-----Original Message-----
>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>Sent: Tuesday, October 25, 2022 5:24 PM
>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>>두산로보틱스
>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>두산로보틱스
>>><sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>두산로보틱스
>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>두산로보틱스
>>><sangjoon.kim@doosan.com>
>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>
>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>>주의하시기 바랍니다.
>>>
>>>CAUTION: This email is sent by an external account. Please take extra
>>>caution when clicking the link or opening the attachment.
>>>
>>>>-----Original Message-----
>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>><dongjoo5.kim@doosan.com>
>>>>Sent: Tuesday, October 25, 2022 3:29 PM
>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>;
>>>>박경훈(Kyunghoon Park) 수석연구원
>>>두산로보틱스
>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>두산로보틱스
>>>><sehyun2.kim@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>>두산로보틱스
>>>><dongjoo5.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>두산로보틱스
>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon
>>>>Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>
>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>
>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>
>>>>I'm dong joo.
>>>>
>>>>After we do a aging test as like latency, We get a system hang about
>>>>ten hours later.
>>>>
>>>>At that time, Our system don't detect usb mouse.
>>>>
>>>>After rebooting our system by force, there is no significative log
>>>>in the kernel log or syslog.
>>>>
>>>>Could you help to us how to solve this issue ?
>>>
>>>Just as mentioned as in https://secure-
>>>web.cisco.com/1ll9UQp4RYnYXuVMxAlJKaDxV1RdMZtBcG3e_jDi4TlIxDMTzF
>>M
>>>tJguJhndpS2BnNhGoAWwBP-G2UCWlarucvId1iz_ea_AU-
>>>U__8Gq6ZgF285KW8SRPHKr7NeWgE4dKG8o8PGMNJ3-
>>>lAB4xdptdPAk1vfJe8AL_Tt6oCEoT0OAr4RrSIjzqtmugt8EHD-
>>>jvxghKHjaWu1eGDkzOYtKpcV8WhZnz1wLItIZdChYT1xlXsFTU7-
>>>GnJhN2jLvMMlZgkMxzQLejJ2aB1wogBTkBIipva21mNGaSFb_sSZhX9ycwiT7U
>M
>>>UfQg5lyHCPZPEeP6/https%3A%2F%2Fxenomai.org%2Fpipermail%2Fxenom
>ai%
>>>2F2022-April%2F047495.html
>>>1. It is highly recommended to use a UART as kernel debug output.
>>>2. enable CONFIG_XENO_OPT_WATCHDOG for xenomai, system will be able
>>to
>>>tell RT application "hangs" (infinite loop at high prio) apart from
>>>real hangs/crashes.
>>>
>>>Regards
>>>
>>>Hongzhan Chen
>>>>
>>>>
>>>>We set up our system as like below sw.
>>>>
>>>>1. Xubuntu 18.04 LTS 32bit
>>>>
>>>>2. Linux kernel 4.1.18 32bit
>>>>
>>>>3. Xenomai 3.0.8 32bit
>>>>
>>>>4. Kernel config
>>>>   We refer to the xenomai page as like below.
>>>>
>>>>https://secure-
>>>web.cisco.com/1nAW3bSL64gGRUPlQWKtShagcypkiReyVX7nhG1T-J
>>>>upEWaqU-3hnCSt542V_mEwX-
>>>_8HsjCaWtSuQnJ3056Yq52DypR5psiqKgrOSq6pbk6xe-tw
>>>>xYZhwwm0akkU4iVwFscbrRTWdk2Ul-
>>>9fU2HilSTJ8rzI8X9LIfFg2foor5t9LawggXyjgq3
>>>>QqwJktjRWEhqL8gFDP2PpsmxrTgVK6NzJdcBxzyOGo_jmjjiO009l74YL2U5Ke
>3
>>A
>>>7kc1AX7
>>>>IV_t016CRGEK4QyAKRuSTqKzFm8t4flDV7eBT4m43w-o_SoFrKq-
>>>AA7ZIKEYPEgpqq/http
>>>>s%3A%2F%2Fsource.denx.de%2FXenomai%2Fxenomai%2F-
>>>>/wikis/Configuring_For_X86_Based_Dual_Kernels#user-content-x86-
>>>>processor-type
>>>>
>>>>Thanks.
>>>>
>>>>-----Original Message-----
>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>Sent: Friday, August 26, 2022 2:40 PM
>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>;
>>>>박경훈(Kyunghoon Park) 수석연구원
>>>두산로보틱스
>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>두산로보틱스
>>>><sehyun2.kim@doosan.com>
>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>
>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>>>주의하시기 바랍니다.
>>>>
>>>>CAUTION: This email is sent by an external account. Please take
>>>>extra caution when clicking the link or opening the attachment.
>>>>
>>>>>-----Original Message-----
>>>>>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>>>>>Sent: Friday, August 26, 2022 10:41 AM
>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>xenomai@xenomai.org
>>>>>Cc: ???(Youngchul Park) ????? ??????
>>>><youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ??????
>>>><kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ??????
>>>><sehyun2.kim@doosan.com>; ???(Dongjoo Kim) ????? ??????
>>>><dongjoo5.kim@doosan.com>
>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>
>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>
>>>>>I'm dong joo.
>>>>>
>>>>>Thank you for your reply to us our questions.
>>>>>
>>>>>And, We have checked the value of TICK_NSEC int our system.
>>>>>
>>>>>#define TICK_NSEC ((NSEC_PER_SEC+HZ/2)/HZ)
>>>>>#define NSEC_PER_SEC   1000000000L
>>>>>HZ  250 ( Max 1000 )
>>>>>
>>>>>The value of TICK_NSEC is defined by linux kernel.
>>>>>And, Both NSEC_PER_SEC and HZ calculate the value of TICK_NSEC.
>>>>>
>>>>>So, The current value of TICK_NSEC is 4ms based on 250 HZ.
>>>>>And, If we change the value of HZ to 1000, The value of TICK_NSEC
>>>>>may be
>>>>1ms.
>>>>>
>>>>>
>>>>>We hope to process a task every 20us using rt_task_yield as like
>>>>>Xenomai
>>>>2.6.5.
>>>>>
>>>>>Is there any method to achieve 20us task delay using rt_task_yield
>>>>>or another
>>>>xenomai method ?
>>>>>And, Is there any problem to reduce the delay more less than TICK_NSEC ?
>>>>
>>>>I just went through the implementation of rt_task_yield of Xeomai
>>>>2.6.5 and found that it is totally different from Xenomai 3.0.8.
>>>>If you want to yield about 20us for current RT thread ,you may try
>>>>call clock_nanosleep .
>>>>.
>>>>Regards
>>>>
>>>>Hongzhan Chen
>>>>>
>>>>>
>>>>>Really Thanks.
>>>>>
>>>>
>>>>
>>>>This e-mail and any attachments herein may contain confidential or
>>>>privileged information and is for the exclusive use of the intended
>>>>recipient(s) named above. If you are not the intended recipient(s),
>>>>you should not disseminate, distribute, retain, copy or otherwise
>>>>use any information contained herein. If you have received this
>>>>e-mail in error, please notify the sender immediately by replying to
>>>>this message and
>>>delete this e-mail and associated attachments.
>>>>Our company does not guarantee this e-mail is secure or free from viruses.
>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>포함하고
>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>>용도로도 이를
>>>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>>>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>>>
>>>
>>>This e-mail and any attachments herein may contain confidential or
>>>privileged information and is for the exclusive use of the intended
>>>recipient(s) named above. If you are not the intended recipient(s),
>>>you should not disseminate, distribute, retain, copy or otherwise use
>>>any information contained herein. If you have received this e-mail in
>>>error, please notify the sender immediately by replying to this
>>>message and
>>delete this e-mail and associated attachments.
>>>Our company does not guarantee this e-mail is secure or free from viruses.
>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를
>>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>>
>>
>>This e-mail and any attachments herein may contain confidential or
>privileged
>>information and is for the exclusive use of the intended recipient(s)
>>named above. If you are not the intended recipient(s), you should not
>>disseminate, distribute, retain, copy or otherwise use any information
>>contained herein. If you have received this e-mail in error, please
>>notify the sender immediately
>by
>>replying to this message and delete this e-mail and associated attachments.
>>Our company does not guarantee this e-mail is secure or free from viruses.
>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로
>>발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못
>수신하신
>>경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기
>>바랍니다. 협조에 감사 드립니다.


This e-mail and any attachments herein may contain confidential or privileged information and is for the exclusive use of the intended recipient(s) named above. If you are not the intended recipient(s), you should not disseminate, distribute, retain, copy or otherwise use any information contained herein. If you have received this e-mail in error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments. Our company does not guarantee this e-mail is secure or free from viruses.
이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[Chen, Hongzhan]

>-----Original Message-----
>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Sent: Thursday, January 5, 2023 5:50 PM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim)
>수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>; 이형석(Hyungseok
>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song) 책임연구원 두산로보틱스
><changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원
>두산로보틱스 <kyungchan.son@doosan.com>; 김동주(Dongjoo Kim)
>책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>I'm really thanks for your support.
>
>
>If we test a rt_mutex_create, rt_mutex_acquire, rt_mutex_release with
>Xenomai 2.6.5,
>The test result is same to Xenomai 3.
>
>Even though we disable rt_mutex_release API, the count increase increase
>abnormally.
>
>Is the result normal case or not ?
>
>Could you share to us the comment about the result ?

Following is the mutex description. When the mutex is owned by current task, it always can enter critical sections but just block any other task per my understanding.

Mutex services.
A mutex is a MUTual EXclusion object, and is useful for protecting shared data structures from concurrent modifications, and implementing critical sections and monitors.

A mutex has two possible states: unlocked (not owned by any task), and locked (owned by one task). A mutex can never be owned by two different tasks simultaneously. A task attempting to lock a mutex that is already locked by another task is blocked until the latter unlocks the mutex first.

Xenomai mutex services enforce a priority inheritance protocol in order to solve priority inversions.

Regards

Hongzhan Chen
>
>Thanks.
>-----Original Message-----
>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>Sent: Thursday, January 5, 2023 6:41 PM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; 김동주(Dongjoo Kim)
>책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>;
>xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim)
>수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>; 이형석(Hyungseok
>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song) 책임연구원 두산로보틱스
><changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원
>두산로보틱스 <kyungchan.son@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>주의하시기 바랍니다.
>
>CAUTION: This email is sent by an external account. Please take extra caution
>when clicking the link or opening the attachment.
>
>>-----Original Message-----
>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>Sent: Thursday, January 5, 2023 5:25 PM
>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스
>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>두산로보틱스
>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song) 책임연구원
>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>선임연구원 두산로보틱스
>><kyungchan.son@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>
>>
>>>-----Original Message-----
>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>><dongjoo5.kim@doosan.com>
>>>Sent: Thursday, January 5, 2023 3:18 PM
>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>두산로보틱스
>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스
>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>두산로보틱스
>>><sangjoon.kim@doosan.com>;
>>이형석(Hyungseok
>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song)
>>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>;
>손경찬(Kyungchan Son) 선임연구원
>>>두산로보틱스 <kyungchan.son@doosan.com>; 김동주(Dongjoo Kim)
>책임연구원 두산로보틱스
>>><dongjoo5.kim@doosan.com>
>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>
>>>Dear Xenomai.org, Chen, Hongzhan
>>>
>>>I'm dong joo.
>>>
>>>Thanks for your support.
>>>
>>>I have one more questions.
>>>
>>>Is the posix-mutex realtime mutex or not ?
>>
>>Yes, it is realtime.
>>
>>>
>>>And, Is there no problem to use the posix-mutex in the realtime Task ?
>>
>>No, I do not think there is problem to use posix-mutex in realttime
>>task. You can see that posix mutex  test already be covered in each
>>release as one of smokey test.
>>
>>>
>>>
>>>Finally, Is there any problem to use the rt_mutex_lock based on
>>>Xenomai guide?
>>
>>From Xenomai 3 , all alchemy APIs such as rt_mutex_* actually is based
>>on posix API, which is quite different from Xenomai 2.
>
>According to doc/asciidoc/MIGRATION.adoc,
>
>- Like +rt_mutex_inquire()+, +rt_cond_inquire()+ does not return the count of
>waiting tasks anymore.
>
>Regards
>
>Hongzhan Chen
>>
>>Regards
>>
>>Hongzhan Chen
>>>
>>>
>>>Thanks.
>>>
>>>-----Original Message-----
>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>Sent: Thursday, January 5, 2023 4:03 PM
>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>두산로보틱스
>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스
>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>두산로보틱스
>>><sangjoon.kim@doosan.com>;
>>이형석(Hyungseok
>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song)
>>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>;
>손경찬(Kyungchan Son) 선임연구원
>>>두산로보틱스 <kyungchan.son@doosan.com>
>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>
>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>주의하시기 바랍니다.
>>>
>>>CAUTION: This email is sent by an external account. Please take extra
>>>caution when clicking the link or opening the attachment.
>>>
>>>Hi
>>>
>>>Why do not you use posix mutex like example in testsuite/smokey/posix-
>>>mutex/posix-mutex.c?
>>>
>>>
>>>Regards
>>>
>>>Hongzhan Chen
>>>
>>>>-----Original Message-----
>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>><dongjoo5.kim@doosan.com>
>>>>Sent: Thursday, January 5, 2023 9:21 AM
>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>두산로보틱스
>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>두산로보틱스
>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>두산로보틱스
>>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>송창우(Changwoo Song) 책임연구원
>>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>>>선임연구원 두산로보틱스
>>>><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>>두산로보틱스
>>>><dongjoo5.kim@doosan.com>
>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>
>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>
>>>>I'm dong joo.
>>>>
>>>>Could you help me to solve this problem ?
>>>>
>>>>Thanks.
>>>>
>>>>-----Original Message-----
>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>><dongjoo5.kim@doosan.com>
>>>>Sent: Monday, January 2, 2023 12:10 PM
>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>두산로보틱스
>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>두산로보틱스
>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>두산로보틱스
>>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>송창우(Changwoo Song) 책임연구원
>>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>>>선임연구원 두산로보틱스
>>>><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>>두산로보틱스
>>>><dongjoo5.kim@doosan.com>
>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>
>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>
>>>>I'm dong joo.
>>>>
>>>>We have tested the API of Xenomai rt_mutex as like rt_mutex_create,
>>>>rt_mutex_acquire, rt_mutex_release.
>>>>
>>>>
>>>>If we block the rt_mutex_release,
>>>>The next sequence can't get a rt_mutex_acquire by the previous
>>>>sequence don't call rt_mutex_release before.
>>>>
>>>>So, The result of count must be 0 what we think.
>>>>
>>>>But, The result of count increase abnormally as like below. Is there
>>>>any problem about rt_mutex_acquire or rt_mutex_release ?
>>>>
>>>>
>>>>If we test the API of Xenomai rt_sem as like rt_sem_create, rt_sem_p,
>>>>rt_sem_v, The result of count is 0.
>>>>
>>>>
>>>>rt_mutex_create 0
>>>>task info
>>>>rt_mutex_acquire 0
>>>>Loop count: 0, Loop time: 355521102 ms rt_mutex_acquire 0 Loop count:
>>>>1, Loop time: 355521103 ms rt_mutex_acquire 0 Loop count: 2, Loop
>>>>time: 355521104 ms rt_mutex_acquire 0 Loop count: 3, Loop time:
>>>>355521105 ms rt_mutex_acquire 0 Loop count: 4, Loop time: 355521106
>>>>ms rt_mutex_acquire 0 Loop count: 5, Loop time: 355521107 ms
>>>>rt_mutex_acquire 0 Loop count: 6, Loop time: 355521108 ms
>>>>rt_mutex_acquire 0 Loop count: 7, Loop time: 355521109 ms
>>>>rt_mutex_acquire 0 Loop count: 8, Loop time: 355521110 ms
>>>>rt_mutex_acquire 0
>>>>
>>>>
>>>>void loop_task_proc(void *arg) {
>>>>
>>>>        int cnt = 0;
>>>>        int ret = 0 ;
>>>>
>>>>        RTIME tstart1;
>>>>
>>>>        RT_MUTEX            m_tMutex;
>>>>//      RT_SEM              m_tSemaphore;
>>>>        ret = rt_mutex_create(&m_tMutex, "test");
>>>>        rt_printf("rt_mutex_create %d\n", ret ) ;
>>>>
>>>>//      ret = rt_sem_create(&m_tSemaphore, "test", 1, S_FIFO);
>>>>//      rt_printf("rt_sem_create %d\n", ret ) ;
>>>>
>>>>        //Print the info
>>>>        rt_printf("task info \n");
>>>>
>>>>        rt_task_set_periodic(NULL, TM_NOW, LOOP_PERIOD);
>>>>
>>>>
>>>>        //Start the task loop
>>>>        while (1) {
>>>>        ret =   rt_mutex_acquire(&m_tMutex, TM_INFINITE );
>>>>        rt_printf("rt_mutex_acquire %d\n", ret ) ;
>>>>
>>>>//      rt_sem_p(&m_tSemaphore, TM_INFINITE ) ;
>>>>//      rt_printf("rt_sem_p %d\n", ret ) ;
>>>>//
>>>>        tstart1 = rt_timer_read () ;
>>>>        rt_printf("Loop count: %d, Loop time: %llu ms\n", cnt,
>>>>tstart1 /
>>>1000000 );
>>>>        cnt++;
>>>>        rt_task_wait_period(NULL);
>>>>
>>>>//      ret =           rt_mutex_release(&m_tMutex);
>>>>//      rt_printf("rt_mutex_release %d\n", ret ) ;
>>>>//      rt_sem_v(&m_tSemaphore);
>>>>//      rt_printf("rt_sem_v %d\n", ret ) ;
>>>>        }
>>>>}
>>>>
>>>>int main(int argc, char* argv[])
>>>>{
>>>>
>>>>        RT_TASK loop_task;
>>>>        rt_task_create(&loop_task, "basicmath_small", 0, 50, 0);
>>>>        rt_task_start(&loop_task, &loop_task_proc, 0);
>>>>        //Wait for Ctrl-C
>>>>        pause();
>>>>        return 0;
>>>>
>>>>
>>>>}
>>>>
>>>>Thanks.
>>>>
>>>>-----Original Message-----
>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>Sent: Wednesday, October 26, 2022 11:43 AM
>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>>><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>>>두산로보틱스
>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>두산로보틱스
>>>><sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>두산로보틱스
>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>두산로보틱스
>>>><sangjoon.kim@doosan.com>; 김동주(Dongjoo
>>>>Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>
>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>
>>>>I'm dong joo.
>>>>
>>>>I have a basic question.
>>>>
>>>>If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI Processor
>>>>CONFIG, We can't check the current cpu freq by sysnode.
>>>>
>>>>Because, sysnode of cpu freq is related to CPU_FREQ CONFIG and ACPI
>>>>Processor CONFIG as i know.
>>>>
>>>>
>>>>If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI Processor
>>>>CONFIG, Could you expect the current cpu freq in the intel hw system ?
>>>>
>>>>Actually, The minimum cpu clock of our hw system is very low.
>>>>
>>>>If our hw system operate with minimum cpu clock always, I worry about
>>>>the performance of hw system.
>>>>
>>>>
>>>>sys/devices/system/cpu/cpu0/cpufreq# ls
>>>>affected_cpus  cpuinfo_cur_freq  cpuinfo_min_freq
>freqdomain_cpus
>>>>scaling_available_frequencies  scaling_cur_freq  scaling_governor
>>>>scaling_min_freq  stats
>>>>bios_limit     cpuinfo_max_freq  cpuinfo_transition_latency  related_cpus
>>>>scaling_available_governors    scaling_driver    scaling_max_freq
>>>>scaling_setspeed
>>>>
>>>>
>>>>Thanks.
>>>>
>>>>-----Original Message-----
>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>Sent: Tuesday, October 25, 2022 5:24 PM
>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>>><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>>>두산로보틱스
>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>두산로보틱스
>>>><sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>두산로보틱스
>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>두산로보틱스
>>>><sangjoon.kim@doosan.com>
>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>
>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>>>주의하시기 바랍니다.
>>>>
>>>>CAUTION: This email is sent by an external account. Please take extra
>>>>caution when clicking the link or opening the attachment.
>>>>
>>>>>-----Original Message-----
>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>><dongjoo5.kim@doosan.com>
>>>>>Sent: Tuesday, October 25, 2022 3:29 PM
>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>xenomai@xenomai.org
>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>;
>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>두산로보틱스
>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>두산로보틱스
>>>>><sehyun2.kim@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>>>두산로보틱스
>>>>><dongjoo5.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>>>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>두산로보틱스
>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon
>>>>>Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>
>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>
>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>
>>>>>I'm dong joo.
>>>>>
>>>>>After we do a aging test as like latency, We get a system hang about
>>>>>ten hours later.
>>>>>
>>>>>At that time, Our system don't detect usb mouse.
>>>>>
>>>>>After rebooting our system by force, there is no significative log
>>>>>in the kernel log or syslog.
>>>>>
>>>>>Could you help to us how to solve this issue ?
>>>>
>>>>Just as mentioned as in https://secure-
>>>>web.cisco.com/1ll9UQp4RYnYXuVMxAlJKaDxV1RdMZtBcG3e_jDi4TlIxDMTz
>F
>>>M
>>>>tJguJhndpS2BnNhGoAWwBP-G2UCWlarucvId1iz_ea_AU-
>>>>U__8Gq6ZgF285KW8SRPHKr7NeWgE4dKG8o8PGMNJ3-
>>>>lAB4xdptdPAk1vfJe8AL_Tt6oCEoT0OAr4RrSIjzqtmugt8EHD-
>>>>jvxghKHjaWu1eGDkzOYtKpcV8WhZnz1wLItIZdChYT1xlXsFTU7-
>>>>GnJhN2jLvMMlZgkMxzQLejJ2aB1wogBTkBIipva21mNGaSFb_sSZhX9ycwiT7
>U
>>M
>>>>UfQg5lyHCPZPEeP6/https%3A%2F%2Fxenomai.org%2Fpipermail%2Fxeno
>m
>>ai%
>>>>2F2022-April%2F047495.html
>>>>1. It is highly recommended to use a UART as kernel debug output.
>>>>2. enable CONFIG_XENO_OPT_WATCHDOG for xenomai, system will be
>able
>>>to
>>>>tell RT application "hangs" (infinite loop at high prio) apart from
>>>>real hangs/crashes.
>>>>
>>>>Regards
>>>>
>>>>Hongzhan Chen
>>>>>
>>>>>
>>>>>We set up our system as like below sw.
>>>>>
>>>>>1. Xubuntu 18.04 LTS 32bit
>>>>>
>>>>>2. Linux kernel 4.1.18 32bit
>>>>>
>>>>>3. Xenomai 3.0.8 32bit
>>>>>
>>>>>4. Kernel config
>>>>>   We refer to the xenomai page as like below.
>>>>>
>>>>>https://secure-
>>>>web.cisco.com/1nAW3bSL64gGRUPlQWKtShagcypkiReyVX7nhG1T-J
>>>>>upEWaqU-3hnCSt542V_mEwX-
>>>>_8HsjCaWtSuQnJ3056Yq52DypR5psiqKgrOSq6pbk6xe-tw
>>>>>xYZhwwm0akkU4iVwFscbrRTWdk2Ul-
>>>>9fU2HilSTJ8rzI8X9LIfFg2foor5t9LawggXyjgq3
>>>>>QqwJktjRWEhqL8gFDP2PpsmxrTgVK6NzJdcBxzyOGo_jmjjiO009l74YL2U5K
>e
>>3
>>>A
>>>>7kc1AX7
>>>>>IV_t016CRGEK4QyAKRuSTqKzFm8t4flDV7eBT4m43w-o_SoFrKq-
>>>>AA7ZIKEYPEgpqq/http
>>>>>s%3A%2F%2Fsource.denx.de%2FXenomai%2Fxenomai%2F-
>>>>>/wikis/Configuring_For_X86_Based_Dual_Kernels#user-content-x86-
>>>>>processor-type
>>>>>
>>>>>Thanks.
>>>>>
>>>>>-----Original Message-----
>>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>>Sent: Friday, August 26, 2022 2:40 PM
>>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>;
>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>두산로보틱스
>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>두산로보틱스
>>>>><sehyun2.kim@doosan.com>
>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>
>>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람
>시
>>>>주의하시기 바랍니다.
>>>>>
>>>>>CAUTION: This email is sent by an external account. Please take
>>>>>extra caution when clicking the link or opening the attachment.
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>>>>>>Sent: Friday, August 26, 2022 10:41 AM
>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>xenomai@xenomai.org
>>>>>>Cc: ???(Youngchul Park) ????? ??????
>>>>><youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ??????
>>>>><kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ??????
>>>>><sehyun2.kim@doosan.com>; ???(Dongjoo Kim) ????? ??????
>>>>><dongjoo5.kim@doosan.com>
>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>
>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>
>>>>>>I'm dong joo.
>>>>>>
>>>>>>Thank you for your reply to us our questions.
>>>>>>
>>>>>>And, We have checked the value of TICK_NSEC int our system.
>>>>>>
>>>>>>#define TICK_NSEC ((NSEC_PER_SEC+HZ/2)/HZ)
>>>>>>#define NSEC_PER_SEC   1000000000L
>>>>>>HZ  250 ( Max 1000 )
>>>>>>
>>>>>>The value of TICK_NSEC is defined by linux kernel.
>>>>>>And, Both NSEC_PER_SEC and HZ calculate the value of TICK_NSEC.
>>>>>>
>>>>>>So, The current value of TICK_NSEC is 4ms based on 250 HZ.
>>>>>>And, If we change the value of HZ to 1000, The value of TICK_NSEC
>>>>>>may be
>>>>>1ms.
>>>>>>
>>>>>>
>>>>>>We hope to process a task every 20us using rt_task_yield as like
>>>>>>Xenomai
>>>>>2.6.5.
>>>>>>
>>>>>>Is there any method to achieve 20us task delay using rt_task_yield
>>>>>>or another
>>>>>xenomai method ?
>>>>>>And, Is there any problem to reduce the delay more less than
>TICK_NSEC ?
>>>>>
>>>>>I just went through the implementation of rt_task_yield of Xeomai
>>>>>2.6.5 and found that it is totally different from Xenomai 3.0.8.
>>>>>If you want to yield about 20us for current RT thread ,you may try
>>>>>call clock_nanosleep .
>>>>>.
>>>>>Regards
>>>>>
>>>>>Hongzhan Chen
>>>>>>
>>>>>>
>>>>>>Really Thanks.
>>>>>>
>>>>>
>>>>>
>>>>>This e-mail and any attachments herein may contain confidential or
>>>>>privileged information and is for the exclusive use of the intended
>>>>>recipient(s) named above. If you are not the intended recipient(s),
>>>>>you should not disseminate, distribute, retain, copy or otherwise
>>>>>use any information contained herein. If you have received this
>>>>>e-mail in error, please notify the sender immediately by replying to
>>>>>this message and
>>>>delete this e-mail and associated attachments.
>>>>>Our company does not guarantee this e-mail is secure or free from
>viruses.
>>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>>포함하고
>>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>>>용도로도 이를
>>>>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>>>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>>>>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>>>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>>>>
>>>>
>>>>This e-mail and any attachments herein may contain confidential or
>>>>privileged information and is for the exclusive use of the intended
>>>>recipient(s) named above. If you are not the intended recipient(s),
>>>>you should not disseminate, distribute, retain, copy or otherwise use
>>>>any information contained herein. If you have received this e-mail in
>>>>error, please notify the sender immediately by replying to this
>>>>message and
>>>delete this e-mail and associated attachments.
>>>>Our company does not guarantee this e-mail is secure or free from viruses.
>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>용도로도 이를
>>>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>>>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>>>
>>>
>>>This e-mail and any attachments herein may contain confidential or
>>privileged
>>>information and is for the exclusive use of the intended recipient(s)
>>>named above. If you are not the intended recipient(s), you should not
>>>disseminate, distribute, retain, copy or otherwise use any information
>>>contained herein. If you have received this e-mail in error, please
>>>notify the sender immediately
>>by
>>>replying to this message and delete this e-mail and associated attachments.
>>>Our company does not guarantee this e-mail is secure or free from viruses.
>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로
>>>발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을
>알려 드립니다. 잘못
>>수신하신
>>>경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기
>>>바랍니다. 협조에 감사 드립니다.
>
>
>This e-mail and any attachments herein may contain confidential or privileged
>information and is for the exclusive use of the intended recipient(s) named
>above. If you are not the intended recipient(s), you should not disseminate,
>distribute, retain, copy or otherwise use any information contained herein. If
>you have received this e-mail in error, please notify the sender immediately by
>replying to this message and delete this e-mail and associated attachments.
>Our company does not guarantee this e-mail is secure or free from viruses.
>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한
>수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를
>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에
>관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신
>경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기
>바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[Chen, Hongzhan]

>-----Original Message-----
>From: Chen, Hongzhan
>Sent: Friday, January 6, 2023 10:36 AM
>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim)
>수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>; 이형석(Hyungseok
>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song) 책임연구원 두산로보틱스
><changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원
>두산로보틱스 <kyungchan.son@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>
>
>>-----Original Message-----
>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>
>>Sent: Thursday, January 5, 2023 5:50 PM
>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim)
>>수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>;
>이형석(Hyungseok
>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>송창우(Changwoo Song) 책임연구원 두산로보틱스
>><changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원
>>두산로보틱스 <kyungchan.son@doosan.com>; 김동주(Dongjoo Kim)
>>책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>Dear Xenomai.org, Chen, Hongzhan
>>
>>I'm dong joo.
>>
>>I'm really thanks for your support.
>>
>>
>>If we test a rt_mutex_create, rt_mutex_acquire, rt_mutex_release with
>>Xenomai 2.6.5,
>>The test result is same to Xenomai 3.
>>
>>Even though we disable rt_mutex_release API, the count increase increase
>>abnormally.
>>
>>Is the result normal case or not ?
>>
>>Could you share to us the comment about the result ?
>
>Following is the mutex description. When the mutex is owned by current task,
>it always can enter critical sections but just block any other task per my
>understanding.
>
>Mutex services.
>A mutex is a MUTual EXclusion object, and is useful for protecting shared data
>structures from concurrent modifications, and implementing critical sections
>and monitors.
>
>A mutex has two possible states: unlocked (not owned by any task), and
>locked (owned by one task). A mutex can never be owned by two different
>tasks simultaneously. A task attempting to lock a mutex that is already locked
>by another task is blocked until the latter unlocks the mutex first.
>
>Xenomai mutex services enforce a priority inheritance protocol in order to
>solve priority inversions.

The implementation of rt_mutex_create set PTHREAD_MUTEX_RECURSIVE attribution by default for the mutex, so the same thread can have multi lock but avoid deadlock. 

Regards

Hongzhan Chen

>
>Regards
>
>Hongzhan Chen
>>
>>Thanks.
>>-----Original Message-----
>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>Sent: Thursday, January 5, 2023 6:41 PM
>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; 김동주(Dongjoo Kim)
>>책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>;
>>xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim)
>>수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>;
>이형석(Hyungseok
>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>송창우(Changwoo Song) 책임연구원 두산로보틱스
>><changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원
>>두산로보틱스 <kyungchan.son@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>>주의하시기 바랍니다.
>>
>>CAUTION: This email is sent by an external account. Please take extra caution
>>when clicking the link or opening the attachment.
>>
>>>-----Original Message-----
>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>Sent: Thursday, January 5, 2023 5:25 PM
>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>두산로보틱스
>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>두산로보틱스
>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>두산로보틱스
>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>송창우(Changwoo Song) 책임연구원
>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>>선임연구원 두산로보틱스
>>><kyungchan.son@doosan.com>
>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>><dongjoo5.kim@doosan.com>
>>>>Sent: Thursday, January 5, 2023 3:18 PM
>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>두산로보틱스
>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>두산로보틱스
>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>두산로보틱스
>>>><sangjoon.kim@doosan.com>;
>>>이형석(Hyungseok
>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>송창우(Changwoo Song)
>>>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>;
>>손경찬(Kyungchan Son) 선임연구원
>>>>두산로보틱스 <kyungchan.son@doosan.com>; 김동주(Dongjoo Kim)
>>책임연구원 두산로보틱스
>>>><dongjoo5.kim@doosan.com>
>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>
>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>
>>>>I'm dong joo.
>>>>
>>>>Thanks for your support.
>>>>
>>>>I have one more questions.
>>>>
>>>>Is the posix-mutex realtime mutex or not ?
>>>
>>>Yes, it is realtime.
>>>
>>>>
>>>>And, Is there no problem to use the posix-mutex in the realtime Task ?
>>>
>>>No, I do not think there is problem to use posix-mutex in realttime
>>>task. You can see that posix mutex  test already be covered in each
>>>release as one of smokey test.
>>>
>>>>
>>>>
>>>>Finally, Is there any problem to use the rt_mutex_lock based on
>>>>Xenomai guide?
>>>
>>>From Xenomai 3 , all alchemy APIs such as rt_mutex_* actually is based
>>>on posix API, which is quite different from Xenomai 2.
>>
>>According to doc/asciidoc/MIGRATION.adoc,
>>
>>- Like +rt_mutex_inquire()+, +rt_cond_inquire()+ does not return the count
>of
>>waiting tasks anymore.
>>
>>Regards
>>
>>Hongzhan Chen
>>>
>>>Regards
>>>
>>>Hongzhan Chen
>>>>
>>>>
>>>>Thanks.
>>>>
>>>>-----Original Message-----
>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>Sent: Thursday, January 5, 2023 4:03 PM
>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>두산로보틱스
>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>두산로보틱스
>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>두산로보틱스
>>>><sangjoon.kim@doosan.com>;
>>>이형석(Hyungseok
>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>송창우(Changwoo Song)
>>>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>;
>>손경찬(Kyungchan Son) 선임연구원
>>>>두산로보틱스 <kyungchan.son@doosan.com>
>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>
>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>>주의하시기 바랍니다.
>>>>
>>>>CAUTION: This email is sent by an external account. Please take extra
>>>>caution when clicking the link or opening the attachment.
>>>>
>>>>Hi
>>>>
>>>>Why do not you use posix mutex like example in testsuite/smokey/posix-
>>>>mutex/posix-mutex.c?
>>>>
>>>>
>>>>Regards
>>>>
>>>>Hongzhan Chen
>>>>
>>>>>-----Original Message-----
>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>><dongjoo5.kim@doosan.com>
>>>>>Sent: Thursday, January 5, 2023 9:21 AM
>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>xenomai@xenomai.org
>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>>>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>두산로보틱스
>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>두산로보틱스
>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>두산로보틱스
>>>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>>송창우(Changwoo Song) 책임연구원
>>>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>>>>선임연구원 두산로보틱스
>>>>><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>>>두산로보틱스
>>>>><dongjoo5.kim@doosan.com>
>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>
>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>
>>>>>I'm dong joo.
>>>>>
>>>>>Could you help me to solve this problem ?
>>>>>
>>>>>Thanks.
>>>>>
>>>>>-----Original Message-----
>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>><dongjoo5.kim@doosan.com>
>>>>>Sent: Monday, January 2, 2023 12:10 PM
>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>xenomai@xenomai.org
>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>>>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>두산로보틱스
>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>두산로보틱스
>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>두산로보틱스
>>>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>>송창우(Changwoo Song) 책임연구원
>>>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>>>>선임연구원 두산로보틱스
>>>>><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>>>두산로보틱스
>>>>><dongjoo5.kim@doosan.com>
>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>
>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>
>>>>>I'm dong joo.
>>>>>
>>>>>We have tested the API of Xenomai rt_mutex as like rt_mutex_create,
>>>>>rt_mutex_acquire, rt_mutex_release.
>>>>>
>>>>>
>>>>>If we block the rt_mutex_release,
>>>>>The next sequence can't get a rt_mutex_acquire by the previous
>>>>>sequence don't call rt_mutex_release before.
>>>>>
>>>>>So, The result of count must be 0 what we think.
>>>>>
>>>>>But, The result of count increase abnormally as like below. Is there
>>>>>any problem about rt_mutex_acquire or rt_mutex_release ?
>>>>>
>>>>>
>>>>>If we test the API of Xenomai rt_sem as like rt_sem_create, rt_sem_p,
>>>>>rt_sem_v, The result of count is 0.
>>>>>
>>>>>
>>>>>rt_mutex_create 0
>>>>>task info
>>>>>rt_mutex_acquire 0
>>>>>Loop count: 0, Loop time: 355521102 ms rt_mutex_acquire 0 Loop count:
>>>>>1, Loop time: 355521103 ms rt_mutex_acquire 0 Loop count: 2, Loop
>>>>>time: 355521104 ms rt_mutex_acquire 0 Loop count: 3, Loop time:
>>>>>355521105 ms rt_mutex_acquire 0 Loop count: 4, Loop time: 355521106
>>>>>ms rt_mutex_acquire 0 Loop count: 5, Loop time: 355521107 ms
>>>>>rt_mutex_acquire 0 Loop count: 6, Loop time: 355521108 ms
>>>>>rt_mutex_acquire 0 Loop count: 7, Loop time: 355521109 ms
>>>>>rt_mutex_acquire 0 Loop count: 8, Loop time: 355521110 ms
>>>>>rt_mutex_acquire 0
>>>>>
>>>>>
>>>>>void loop_task_proc(void *arg) {
>>>>>
>>>>>        int cnt = 0;
>>>>>        int ret = 0 ;
>>>>>
>>>>>        RTIME tstart1;
>>>>>
>>>>>        RT_MUTEX            m_tMutex;
>>>>>//      RT_SEM              m_tSemaphore;
>>>>>        ret = rt_mutex_create(&m_tMutex, "test");
>>>>>        rt_printf("rt_mutex_create %d\n", ret ) ;
>>>>>
>>>>>//      ret = rt_sem_create(&m_tSemaphore, "test", 1, S_FIFO);
>>>>>//      rt_printf("rt_sem_create %d\n", ret ) ;
>>>>>
>>>>>        //Print the info
>>>>>        rt_printf("task info \n");
>>>>>
>>>>>        rt_task_set_periodic(NULL, TM_NOW, LOOP_PERIOD);
>>>>>
>>>>>
>>>>>        //Start the task loop
>>>>>        while (1) {
>>>>>        ret =   rt_mutex_acquire(&m_tMutex, TM_INFINITE );
>>>>>        rt_printf("rt_mutex_acquire %d\n", ret ) ;
>>>>>
>>>>>//      rt_sem_p(&m_tSemaphore, TM_INFINITE ) ;
>>>>>//      rt_printf("rt_sem_p %d\n", ret ) ;
>>>>>//
>>>>>        tstart1 = rt_timer_read () ;
>>>>>        rt_printf("Loop count: %d, Loop time: %llu ms\n", cnt,
>>>>>tstart1 /
>>>>1000000 );
>>>>>        cnt++;
>>>>>        rt_task_wait_period(NULL);
>>>>>
>>>>>//      ret =           rt_mutex_release(&m_tMutex);
>>>>>//      rt_printf("rt_mutex_release %d\n", ret ) ;
>>>>>//      rt_sem_v(&m_tSemaphore);
>>>>>//      rt_printf("rt_sem_v %d\n", ret ) ;
>>>>>        }
>>>>>}
>>>>>
>>>>>int main(int argc, char* argv[])
>>>>>{
>>>>>
>>>>>        RT_TASK loop_task;
>>>>>        rt_task_create(&loop_task, "basicmath_small", 0, 50, 0);
>>>>>        rt_task_start(&loop_task, &loop_task_proc, 0);
>>>>>        //Wait for Ctrl-C
>>>>>        pause();
>>>>>        return 0;
>>>>>
>>>>>
>>>>>}
>>>>>
>>>>>Thanks.
>>>>>
>>>>>-----Original Message-----
>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>>Sent: Wednesday, October 26, 2022 11:43 AM
>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>xenomai@xenomai.org
>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>>>><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>>>>두산로보틱스
>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>두산로보틱스
>>>>><sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>>>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>두산로보틱스
>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>두산로보틱스
>>>>><sangjoon.kim@doosan.com>; 김동주(Dongjoo
>>>>>Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>
>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>
>>>>>I'm dong joo.
>>>>>
>>>>>I have a basic question.
>>>>>
>>>>>If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI
>Processor
>>>>>CONFIG, We can't check the current cpu freq by sysnode.
>>>>>
>>>>>Because, sysnode of cpu freq is related to CPU_FREQ CONFIG and ACPI
>>>>>Processor CONFIG as i know.
>>>>>
>>>>>
>>>>>If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI
>Processor
>>>>>CONFIG, Could you expect the current cpu freq in the intel hw system ?
>>>>>
>>>>>Actually, The minimum cpu clock of our hw system is very low.
>>>>>
>>>>>If our hw system operate with minimum cpu clock always, I worry about
>>>>>the performance of hw system.
>>>>>
>>>>>
>>>>>sys/devices/system/cpu/cpu0/cpufreq# ls
>>>>>affected_cpus  cpuinfo_cur_freq  cpuinfo_min_freq
>>freqdomain_cpus
>>>>>scaling_available_frequencies  scaling_cur_freq  scaling_governor
>>>>>scaling_min_freq  stats
>>>>>bios_limit     cpuinfo_max_freq  cpuinfo_transition_latency  related_cpus
>>>>>scaling_available_governors    scaling_driver    scaling_max_freq
>>>>>scaling_setspeed
>>>>>
>>>>>
>>>>>Thanks.
>>>>>
>>>>>-----Original Message-----
>>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>>Sent: Tuesday, October 25, 2022 5:24 PM
>>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>>>><youngchul3.park@doosan.com>; 박경훈(Kyunghoon Park) 수석연구원
>>>>두산로보틱스
>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>두산로보틱스
>>>>><sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>>>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>두산로보틱스
>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>두산로보틱스
>>>>><sangjoon.kim@doosan.com>
>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>
>>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람
>시
>>>>주의하시기 바랍니다.
>>>>>
>>>>>CAUTION: This email is sent by an external account. Please take extra
>>>>>caution when clicking the link or opening the attachment.
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>>><dongjoo5.kim@doosan.com>
>>>>>>Sent: Tuesday, October 25, 2022 3:29 PM
>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>xenomai@xenomai.org
>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>;
>>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>>두산로보틱스
>>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>>두산로보틱스
>>>>>><sehyun2.kim@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>>>>두산로보틱스
>>>>>><dongjoo5.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>>>>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>두산로보틱스
>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon
>>>>>>Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>
>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>
>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>
>>>>>>I'm dong joo.
>>>>>>
>>>>>>After we do a aging test as like latency, We get a system hang about
>>>>>>ten hours later.
>>>>>>
>>>>>>At that time, Our system don't detect usb mouse.
>>>>>>
>>>>>>After rebooting our system by force, there is no significative log
>>>>>>in the kernel log or syslog.
>>>>>>
>>>>>>Could you help to us how to solve this issue ?
>>>>>
>>>>>Just as mentioned as in https://secure-
>>>>>web.cisco.com/1ll9UQp4RYnYXuVMxAlJKaDxV1RdMZtBcG3e_jDi4TlIxDM
>Tz
>>F
>>>>M
>>>>>tJguJhndpS2BnNhGoAWwBP-G2UCWlarucvId1iz_ea_AU-
>>>>>U__8Gq6ZgF285KW8SRPHKr7NeWgE4dKG8o8PGMNJ3-
>>>>>lAB4xdptdPAk1vfJe8AL_Tt6oCEoT0OAr4RrSIjzqtmugt8EHD-
>>>>>jvxghKHjaWu1eGDkzOYtKpcV8WhZnz1wLItIZdChYT1xlXsFTU7-
>>>>>GnJhN2jLvMMlZgkMxzQLejJ2aB1wogBTkBIipva21mNGaSFb_sSZhX9ycwiT7
>>U
>>>M
>>>>>UfQg5lyHCPZPEeP6/https%3A%2F%2Fxenomai.org%2Fpipermail%2Fxeno
>>m
>>>ai%
>>>>>2F2022-April%2F047495.html
>>>>>1. It is highly recommended to use a UART as kernel debug output.
>>>>>2. enable CONFIG_XENO_OPT_WATCHDOG for xenomai, system will be
>>able
>>>>to
>>>>>tell RT application "hangs" (infinite loop at high prio) apart from
>>>>>real hangs/crashes.
>>>>>
>>>>>Regards
>>>>>
>>>>>Hongzhan Chen
>>>>>>
>>>>>>
>>>>>>We set up our system as like below sw.
>>>>>>
>>>>>>1. Xubuntu 18.04 LTS 32bit
>>>>>>
>>>>>>2. Linux kernel 4.1.18 32bit
>>>>>>
>>>>>>3. Xenomai 3.0.8 32bit
>>>>>>
>>>>>>4. Kernel config
>>>>>>   We refer to the xenomai page as like below.
>>>>>>
>>>>>>https://secure-
>>>>>web.cisco.com/1nAW3bSL64gGRUPlQWKtShagcypkiReyVX7nhG1T-J
>>>>>>upEWaqU-3hnCSt542V_mEwX-
>>>>>_8HsjCaWtSuQnJ3056Yq52DypR5psiqKgrOSq6pbk6xe-tw
>>>>>>xYZhwwm0akkU4iVwFscbrRTWdk2Ul-
>>>>>9fU2HilSTJ8rzI8X9LIfFg2foor5t9LawggXyjgq3
>>>>>>QqwJktjRWEhqL8gFDP2PpsmxrTgVK6NzJdcBxzyOGo_jmjjiO009l74YL2U5
>K
>>e
>>>3
>>>>A
>>>>>7kc1AX7
>>>>>>IV_t016CRGEK4QyAKRuSTqKzFm8t4flDV7eBT4m43w-o_SoFrKq-
>>>>>AA7ZIKEYPEgpqq/http
>>>>>>s%3A%2F%2Fsource.denx.de%2FXenomai%2Fxenomai%2F-
>>>>>>/wikis/Configuring_For_X86_Based_Dual_Kernels#user-content-x86-
>>>>>>processor-type
>>>>>>
>>>>>>Thanks.
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>>>Sent: Friday, August 26, 2022 2:40 PM
>>>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>;
>>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>>두산로보틱스
>>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>>두산로보틱스
>>>>>><sehyun2.kim@doosan.com>
>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>
>>>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람
>>시
>>>>>주의하시기 바랍니다.
>>>>>>
>>>>>>CAUTION: This email is sent by an external account. Please take
>>>>>>extra caution when clicking the link or opening the attachment.
>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>>>>>>>Sent: Friday, August 26, 2022 10:41 AM
>>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>>xenomai@xenomai.org
>>>>>>>Cc: ???(Youngchul Park) ????? ??????
>>>>>><youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ??????
>>>>>><kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ??????
>>>>>><sehyun2.kim@doosan.com>; ???(Dongjoo Kim) ????? ??????
>>>>>><dongjoo5.kim@doosan.com>
>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>
>>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>>
>>>>>>>I'm dong joo.
>>>>>>>
>>>>>>>Thank you for your reply to us our questions.
>>>>>>>
>>>>>>>And, We have checked the value of TICK_NSEC int our system.
>>>>>>>
>>>>>>>#define TICK_NSEC ((NSEC_PER_SEC+HZ/2)/HZ)
>>>>>>>#define NSEC_PER_SEC   1000000000L
>>>>>>>HZ  250 ( Max 1000 )
>>>>>>>
>>>>>>>The value of TICK_NSEC is defined by linux kernel.
>>>>>>>And, Both NSEC_PER_SEC and HZ calculate the value of TICK_NSEC.
>>>>>>>
>>>>>>>So, The current value of TICK_NSEC is 4ms based on 250 HZ.
>>>>>>>And, If we change the value of HZ to 1000, The value of TICK_NSEC
>>>>>>>may be
>>>>>>1ms.
>>>>>>>
>>>>>>>
>>>>>>>We hope to process a task every 20us using rt_task_yield as like
>>>>>>>Xenomai
>>>>>>2.6.5.
>>>>>>>
>>>>>>>Is there any method to achieve 20us task delay using rt_task_yield
>>>>>>>or another
>>>>>>xenomai method ?
>>>>>>>And, Is there any problem to reduce the delay more less than
>>TICK_NSEC ?
>>>>>>
>>>>>>I just went through the implementation of rt_task_yield of Xeomai
>>>>>>2.6.5 and found that it is totally different from Xenomai 3.0.8.
>>>>>>If you want to yield about 20us for current RT thread ,you may try
>>>>>>call clock_nanosleep .
>>>>>>.
>>>>>>Regards
>>>>>>
>>>>>>Hongzhan Chen
>>>>>>>
>>>>>>>
>>>>>>>Really Thanks.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>This e-mail and any attachments herein may contain confidential or
>>>>>>privileged information and is for the exclusive use of the intended
>>>>>>recipient(s) named above. If you are not the intended recipient(s),
>>>>>>you should not disseminate, distribute, retain, copy or otherwise
>>>>>>use any information contained herein. If you have received this
>>>>>>e-mail in error, please notify the sender immediately by replying to
>>>>>>this message and
>>>>>delete this e-mail and associated attachments.
>>>>>>Our company does not guarantee this e-mail is secure or free from
>>viruses.
>>>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>>>포함하고
>>>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>>>>용도로도 이를
>>>>>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>>>>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>>>>>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>>>>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>>>>>
>>>>>
>>>>>This e-mail and any attachments herein may contain confidential or
>>>>>privileged information and is for the exclusive use of the intended
>>>>>recipient(s) named above. If you are not the intended recipient(s),
>>>>>you should not disseminate, distribute, retain, copy or otherwise use
>>>>>any information contained herein. If you have received this e-mail in
>>>>>error, please notify the sender immediately by replying to this
>>>>>message and
>>>>delete this e-mail and associated attachments.
>>>>>Our company does not guarantee this e-mail is secure or free from
>viruses.
>>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>>포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>>용도로도 이를
>>>>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>>>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>>>>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>>>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>>>>
>>>>
>>>>This e-mail and any attachments herein may contain confidential or
>>>privileged
>>>>information and is for the exclusive use of the intended recipient(s)
>>>>named above. If you are not the intended recipient(s), you should not
>>>>disseminate, distribute, retain, copy or otherwise use any information
>>>>contained herein. If you have received this e-mail in error, please
>>>>notify the sender immediately
>>>by
>>>>replying to this message and delete this e-mail and associated attachments.
>>>>Our company does not guarantee this e-mail is secure or free from viruses.
>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>포함하고
>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>>용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로
>>>>발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을
>>알려 드립니다. 잘못
>>>수신하신
>>>>경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기
>>>>바랍니다. 협조에 감사 드립니다.
>>
>>
>>This e-mail and any attachments herein may contain confidential or
>privileged
>>information and is for the exclusive use of the intended recipient(s) named
>>above. If you are not the intended recipient(s), you should not disseminate,
>>distribute, retain, copy or otherwise use any information contained herein. If
>>you have received this e-mail in error, please notify the sender immediately
>by
>>replying to this message and delete this e-mail and associated attachments.
>>Our company does not guarantee this e-mail is secure or free from viruses.
>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한
>>수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를
>>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에
>>관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못
>수신하신
>>경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기
>>바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[김동주(Dongjoo Kim) 책임연구원 두산로보틱스]

Dear Xenomai.org, Chen, Hongzhan

I'm dong joo.

I'm really thanks for your support.


If we apply as like below functions, The error result is not same.
Could you explain the difference between rt_task_sleep()and clock_nanosleep() ?


And, If our code run a cpu,
Is there any possibility to act context switching by other process ?


Is the Xenomai Scheduler preemption or non- preemption ?


While ( 1 ) {

rt_task_sleep(1000000 );

our code start ;
our cod end ;

}

: The result is segfault by our code.


While ( 1 ) {

struct timespec ts;
      ts.tv_sec = 0;
      ts.tv_nsec = 1000000; /* 1ms */

clock_nanosleep(CLOCK_REALTIME, 0, &ts, NULL);

our code start ;
our cod end ;

}

: The result is Xenomai watchdog as like below.
   by Xenomai/cobalt: watchdog triggered CPU time limit exceeded (core dumped)


Thanks.
-----Original Message-----
From: Chen, Hongzhan <hongzhan.chen@intel.com>
Sent: Wednesday, January 11, 2023 12:14 AM
To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>; xenomai@xenomai.org
Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스 <sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>; 이형석(Hyungseok Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>; 송창우(Changwoo Song) 책임연구원 두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원 두산로보틱스 <kyungchan.son@doosan.com>
Subject: RE: What causes the latency of the rt_task_yield() API?

주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시 주의하시기 바랍니다.

CAUTION: This email is sent by an external account. Please take extra caution when clicking the link or opening the attachment.

>-----Original Message-----
>From: Chen, Hongzhan
>Sent: Friday, January 6, 2023 10:36 AM
>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스
><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스
><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>; 송창우(Changwoo Song) 책임연구원
>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원 두산로보틱스
><kyungchan.son@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>
>
>>-----Original Message-----
>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>
>>Sent: Thursday, January 5, 2023 5:50 PM
>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스
>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스
>><sangjoon.kim@doosan.com>;
>이형석(Hyungseok
>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>; 송창우(Changwoo Song)
>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원
>>두산로보틱스 <kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>Dear Xenomai.org, Chen, Hongzhan
>>
>>I'm dong joo.
>>
>>I'm really thanks for your support.
>>
>>
>>If we test a rt_mutex_create, rt_mutex_acquire, rt_mutex_release with
>>Xenomai 2.6.5, The test result is same to Xenomai 3.
>>
>>Even though we disable rt_mutex_release API, the count increase
>>increase abnormally.
>>
>>Is the result normal case or not ?
>>
>>Could you share to us the comment about the result ?
>
>Following is the mutex description. When the mutex is owned by current
>task, it always can enter critical sections but just block any other
>task per my understanding.
>
>Mutex services.
>A mutex is a MUTual EXclusion object, and is useful for protecting
>shared data structures from concurrent modifications, and implementing
>critical sections and monitors.
>
>A mutex has two possible states: unlocked (not owned by any task), and
>locked (owned by one task). A mutex can never be owned by two different
>tasks simultaneously. A task attempting to lock a mutex that is already
>locked by another task is blocked until the latter unlocks the mutex first.
>
>Xenomai mutex services enforce a priority inheritance protocol in order
>to solve priority inversions.

The implementation of rt_mutex_create set PTHREAD_MUTEX_RECURSIVE attribution by default for the mutex, so the same thread can have multi lock but avoid deadlock.

Regards

Hongzhan Chen

>
>Regards
>
>Hongzhan Chen
>>
>>Thanks.
>>-----Original Message-----
>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>Sent: Thursday, January 5, 2023 6:41 PM
>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; 김동주(Dongjoo Kim) 책임연구원
>>두산로보틱스 <dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스
>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스
>><sangjoon.kim@doosan.com>;
>이형석(Hyungseok
>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>; 송창우(Changwoo Song)
>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원
>>두산로보틱스 <kyungchan.son@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시 주의하시기 바랍니다.
>>
>>CAUTION: This email is sent by an external account. Please take extra
>>caution when clicking the link or opening the attachment.
>>
>>>-----Original Message-----
>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>Sent: Thursday, January 5, 2023 5:25 PM
>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>두산로보틱스
>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>두산로보틱스
>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>두산로보틱스
>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>송창우(Changwoo Song) 책임연구원
>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>>선임연구원 두산로보틱스
>>><kyungchan.son@doosan.com>
>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>><dongjoo5.kim@doosan.com>
>>>>Sent: Thursday, January 5, 2023 3:18 PM
>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>;
>>>>김세현(Sehyun Kim) 연구원
>>>두산로보틱스
>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>두산로보틱스
>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>두산로보틱스
>>>><sangjoon.kim@doosan.com>;
>>>이형석(Hyungseok
>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>송창우(Changwoo Song)
>>>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>;
>>손경찬(Kyungchan Son) 선임연구원
>>>>두산로보틱스 <kyungchan.son@doosan.com>; 김동주(Dongjoo Kim)
>>책임연구원 두산로보틱스
>>>><dongjoo5.kim@doosan.com>
>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>
>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>
>>>>I'm dong joo.
>>>>
>>>>Thanks for your support.
>>>>
>>>>I have one more questions.
>>>>
>>>>Is the posix-mutex realtime mutex or not ?
>>>
>>>Yes, it is realtime.
>>>
>>>>
>>>>And, Is there no problem to use the posix-mutex in the realtime Task ?
>>>
>>>No, I do not think there is problem to use posix-mutex in realttime
>>>task. You can see that posix mutex  test already be covered in each
>>>release as one of smokey test.
>>>
>>>>
>>>>
>>>>Finally, Is there any problem to use the rt_mutex_lock based on
>>>>Xenomai guide?
>>>
>>>From Xenomai 3 , all alchemy APIs such as rt_mutex_* actually is
>>>based on posix API, which is quite different from Xenomai 2.
>>
>>According to doc/asciidoc/MIGRATION.adoc,
>>
>>- Like +rt_mutex_inquire()+, +rt_cond_inquire()+ does not return the
>>count
>of
>>waiting tasks anymore.
>>
>>Regards
>>
>>Hongzhan Chen
>>>
>>>Regards
>>>
>>>Hongzhan Chen
>>>>
>>>>
>>>>Thanks.
>>>>
>>>>-----Original Message-----
>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>Sent: Thursday, January 5, 2023 4:03 PM
>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>;
>>>>김세현(Sehyun Kim) 연구원
>>>두산로보틱스
>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>두산로보틱스
>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>두산로보틱스
>>>><sangjoon.kim@doosan.com>;
>>>이형석(Hyungseok
>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>송창우(Changwoo Song)
>>>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>;
>>손경찬(Kyungchan Son) 선임연구원
>>>>두산로보틱스 <kyungchan.son@doosan.com>
>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>
>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>>주의하시기 바랍니다.
>>>>
>>>>CAUTION: This email is sent by an external account. Please take
>>>>extra caution when clicking the link or opening the attachment.
>>>>
>>>>Hi
>>>>
>>>>Why do not you use posix mutex like example in
>>>>testsuite/smokey/posix- mutex/posix-mutex.c?
>>>>
>>>>
>>>>Regards
>>>>
>>>>Hongzhan Chen
>>>>
>>>>>-----Original Message-----
>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
>>>>>Sent: Thursday, January 5, 2023 9:21 AM
>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>xenomai@xenomai.org
>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>;
>>>>>김세현(Sehyun Kim) 연구원
>>>>두산로보틱스
>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>두산로보틱스
>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>두산로보틱스
>>>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>>송창우(Changwoo Song) 책임연구원
>>>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>>>>선임연구원 두산로보틱스
>>>>><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>>>두산로보틱스
>>>>><dongjoo5.kim@doosan.com>
>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>
>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>
>>>>>I'm dong joo.
>>>>>
>>>>>Could you help me to solve this problem ?
>>>>>
>>>>>Thanks.
>>>>>
>>>>>-----Original Message-----
>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
>>>>>Sent: Monday, January 2, 2023 12:10 PM
>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>xenomai@xenomai.org
>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>;
>>>>>김세현(Sehyun Kim) 연구원
>>>>두산로보틱스
>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>두산로보틱스
>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>두산로보틱스
>>>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>>송창우(Changwoo Song) 책임연구원
>>>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>>>>선임연구원 두산로보틱스
>>>>><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>>>두산로보틱스
>>>>><dongjoo5.kim@doosan.com>
>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>
>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>
>>>>>I'm dong joo.
>>>>>
>>>>>We have tested the API of Xenomai rt_mutex as like rt_mutex_create,
>>>>>rt_mutex_acquire, rt_mutex_release.
>>>>>
>>>>>
>>>>>If we block the rt_mutex_release,
>>>>>The next sequence can't get a rt_mutex_acquire by the previous
>>>>>sequence don't call rt_mutex_release before.
>>>>>
>>>>>So, The result of count must be 0 what we think.
>>>>>
>>>>>But, The result of count increase abnormally as like below. Is
>>>>>there any problem about rt_mutex_acquire or rt_mutex_release ?
>>>>>
>>>>>
>>>>>If we test the API of Xenomai rt_sem as like rt_sem_create,
>>>>>rt_sem_p, rt_sem_v, The result of count is 0.
>>>>>
>>>>>
>>>>>rt_mutex_create 0
>>>>>task info
>>>>>rt_mutex_acquire 0
>>>>>Loop count: 0, Loop time: 355521102 ms rt_mutex_acquire 0 Loop count:
>>>>>1, Loop time: 355521103 ms rt_mutex_acquire 0 Loop count: 2, Loop
>>>>>time: 355521104 ms rt_mutex_acquire 0 Loop count: 3, Loop time:
>>>>>355521105 ms rt_mutex_acquire 0 Loop count: 4, Loop time: 355521106
>>>>>ms rt_mutex_acquire 0 Loop count: 5, Loop time: 355521107 ms
>>>>>rt_mutex_acquire 0 Loop count: 6, Loop time: 355521108 ms
>>>>>rt_mutex_acquire 0 Loop count: 7, Loop time: 355521109 ms
>>>>>rt_mutex_acquire 0 Loop count: 8, Loop time: 355521110 ms
>>>>>rt_mutex_acquire 0
>>>>>
>>>>>
>>>>>void loop_task_proc(void *arg) {
>>>>>
>>>>>        int cnt = 0;
>>>>>        int ret = 0 ;
>>>>>
>>>>>        RTIME tstart1;
>>>>>
>>>>>        RT_MUTEX            m_tMutex;
>>>>>//      RT_SEM              m_tSemaphore;
>>>>>        ret = rt_mutex_create(&m_tMutex, "test");
>>>>>        rt_printf("rt_mutex_create %d\n", ret ) ;
>>>>>
>>>>>//      ret = rt_sem_create(&m_tSemaphore, "test", 1, S_FIFO);
>>>>>//      rt_printf("rt_sem_create %d\n", ret ) ;
>>>>>
>>>>>        //Print the info
>>>>>        rt_printf("task info \n");
>>>>>
>>>>>        rt_task_set_periodic(NULL, TM_NOW, LOOP_PERIOD);
>>>>>
>>>>>
>>>>>        //Start the task loop
>>>>>        while (1) {
>>>>>        ret =   rt_mutex_acquire(&m_tMutex, TM_INFINITE );
>>>>>        rt_printf("rt_mutex_acquire %d\n", ret ) ;
>>>>>
>>>>>//      rt_sem_p(&m_tSemaphore, TM_INFINITE ) ;
>>>>>//      rt_printf("rt_sem_p %d\n", ret ) ;
>>>>>//
>>>>>        tstart1 = rt_timer_read () ;
>>>>>        rt_printf("Loop count: %d, Loop time: %llu ms\n", cnt,
>>>>>tstart1 /
>>>>1000000 );
>>>>>        cnt++;
>>>>>        rt_task_wait_period(NULL);
>>>>>
>>>>>//      ret =           rt_mutex_release(&m_tMutex);
>>>>>//      rt_printf("rt_mutex_release %d\n", ret ) ;
>>>>>//      rt_sem_v(&m_tSemaphore);
>>>>>//      rt_printf("rt_sem_v %d\n", ret ) ;
>>>>>        }
>>>>>}
>>>>>
>>>>>int main(int argc, char* argv[])
>>>>>{
>>>>>
>>>>>        RT_TASK loop_task;
>>>>>        rt_task_create(&loop_task, "basicmath_small", 0, 50, 0);
>>>>>        rt_task_start(&loop_task, &loop_task_proc, 0);
>>>>>        //Wait for Ctrl-C
>>>>>        pause();
>>>>>        return 0;
>>>>>
>>>>>
>>>>>}
>>>>>
>>>>>Thanks.
>>>>>
>>>>>-----Original Message-----
>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>>Sent: Wednesday, October 26, 2022 11:43 AM
>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>xenomai@xenomai.org
>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>;
>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>두산로보틱스
>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>두산로보틱스
>>>>><sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>>>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>두산로보틱스
>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>두산로보틱스
>>>>><sangjoon.kim@doosan.com>; 김동주(Dongjoo
>>>>>Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>
>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>
>>>>>I'm dong joo.
>>>>>
>>>>>I have a basic question.
>>>>>
>>>>>If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI
>Processor
>>>>>CONFIG, We can't check the current cpu freq by sysnode.
>>>>>
>>>>>Because, sysnode of cpu freq is related to CPU_FREQ CONFIG and ACPI
>>>>>Processor CONFIG as i know.
>>>>>
>>>>>
>>>>>If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI
>Processor
>>>>>CONFIG, Could you expect the current cpu freq in the intel hw system ?
>>>>>
>>>>>Actually, The minimum cpu clock of our hw system is very low.
>>>>>
>>>>>If our hw system operate with minimum cpu clock always, I worry
>>>>>about the performance of hw system.
>>>>>
>>>>>
>>>>>sys/devices/system/cpu/cpu0/cpufreq# ls affected_cpus
>>>>>cpuinfo_cur_freq  cpuinfo_min_freq
>>freqdomain_cpus
>>>>>scaling_available_frequencies  scaling_cur_freq  scaling_governor
>>>>>scaling_min_freq  stats
>>>>>bios_limit     cpuinfo_max_freq  cpuinfo_transition_latency  related_cpus
>>>>>scaling_available_governors    scaling_driver    scaling_max_freq
>>>>>scaling_setspeed
>>>>>
>>>>>
>>>>>Thanks.
>>>>>
>>>>>-----Original Message-----
>>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>>Sent: Tuesday, October 25, 2022 5:24 PM
>>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>;
>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>두산로보틱스
>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>두산로보틱스
>>>>><sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>>>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>두산로보틱스
>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>두산로보틱스
>>>>><sangjoon.kim@doosan.com>
>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>
>>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람
>시
>>>>주의하시기 바랍니다.
>>>>>
>>>>>CAUTION: This email is sent by an external account. Please take
>>>>>extra caution when clicking the link or opening the attachment.
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
>>>>>>Sent: Tuesday, October 25, 2022 3:29 PM
>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>xenomai@xenomai.org
>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>;
>>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>>두산로보틱스
>>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>>두산로보틱스
>>>>>><sehyun2.kim@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>>>>두산로보틱스
>>>>>><dongjoo5.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>>>>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>두산로보틱스
>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon
>>>>>>Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>
>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>
>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>
>>>>>>I'm dong joo.
>>>>>>
>>>>>>After we do a aging test as like latency, We get a system hang
>>>>>>about ten hours later.
>>>>>>
>>>>>>At that time, Our system don't detect usb mouse.
>>>>>>
>>>>>>After rebooting our system by force, there is no significative log
>>>>>>in the kernel log or syslog.
>>>>>>
>>>>>>Could you help to us how to solve this issue ?
>>>>>
>>>>>Just as mentioned as in https://secure-
>>>>>web.cisco.com/1ll9UQp4RYnYXuVMxAlJKaDxV1RdMZtBcG3e_jDi4TlIxDM
>Tz
>>F
>>>>M
>>>>>tJguJhndpS2BnNhGoAWwBP-G2UCWlarucvId1iz_ea_AU-
>>>>>U__8Gq6ZgF285KW8SRPHKr7NeWgE4dKG8o8PGMNJ3-
>>>>>lAB4xdptdPAk1vfJe8AL_Tt6oCEoT0OAr4RrSIjzqtmugt8EHD-
>>>>>jvxghKHjaWu1eGDkzOYtKpcV8WhZnz1wLItIZdChYT1xlXsFTU7-
>>>>>GnJhN2jLvMMlZgkMxzQLejJ2aB1wogBTkBIipva21mNGaSFb_sSZhX9ycwiT7
>>U
>>>M
>>>>>UfQg5lyHCPZPEeP6/https%3A%2F%2Fxenomai.org%2Fpipermail%2Fxeno
>>m
>>>ai%
>>>>>2F2022-April%2F047495.html
>>>>>1. It is highly recommended to use a UART as kernel debug output.
>>>>>2. enable CONFIG_XENO_OPT_WATCHDOG for xenomai, system will be
>>able
>>>>to
>>>>>tell RT application "hangs" (infinite loop at high prio) apart from
>>>>>real hangs/crashes.
>>>>>
>>>>>Regards
>>>>>
>>>>>Hongzhan Chen
>>>>>>
>>>>>>
>>>>>>We set up our system as like below sw.
>>>>>>
>>>>>>1. Xubuntu 18.04 LTS 32bit
>>>>>>
>>>>>>2. Linux kernel 4.1.18 32bit
>>>>>>
>>>>>>3. Xenomai 3.0.8 32bit
>>>>>>
>>>>>>4. Kernel config
>>>>>>   We refer to the xenomai page as like below.
>>>>>>
>>>>>>https://secure-
>>>>>web.cisco.com/1nAW3bSL64gGRUPlQWKtShagcypkiReyVX7nhG1T-J
>>>>>>upEWaqU-3hnCSt542V_mEwX-
>>>>>_8HsjCaWtSuQnJ3056Yq52DypR5psiqKgrOSq6pbk6xe-tw
>>>>>>xYZhwwm0akkU4iVwFscbrRTWdk2Ul-
>>>>>9fU2HilSTJ8rzI8X9LIfFg2foor5t9LawggXyjgq3
>>>>>>QqwJktjRWEhqL8gFDP2PpsmxrTgVK6NzJdcBxzyOGo_jmjjiO009l74YL2U5
>K
>>e
>>>3
>>>>A
>>>>>7kc1AX7
>>>>>>IV_t016CRGEK4QyAKRuSTqKzFm8t4flDV7eBT4m43w-o_SoFrKq-
>>>>>AA7ZIKEYPEgpqq/http
>>>>>>s%3A%2F%2Fsource.denx.de%2FXenomai%2Fxenomai%2F-
>>>>>>/wikis/Configuring_For_X86_Based_Dual_Kernels#user-content-x86-
>>>>>>processor-type
>>>>>>
>>>>>>Thanks.
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>>>Sent: Friday, August 26, 2022 2:40 PM
>>>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>;
>>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>>두산로보틱스
>>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>>두산로보틱스
>>>>>><sehyun2.kim@doosan.com>
>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>
>>>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람
>>시
>>>>>주의하시기 바랍니다.
>>>>>>
>>>>>>CAUTION: This email is sent by an external account. Please take
>>>>>>extra caution when clicking the link or opening the attachment.
>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>>>>>>>Sent: Friday, August 26, 2022 10:41 AM
>>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>>xenomai@xenomai.org
>>>>>>>Cc: ???(Youngchul Park) ????? ??????
>>>>>><youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ??????
>>>>>><kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ??????
>>>>>><sehyun2.kim@doosan.com>; ???(Dongjoo Kim) ????? ??????
>>>>>><dongjoo5.kim@doosan.com>
>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>
>>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>>
>>>>>>>I'm dong joo.
>>>>>>>
>>>>>>>Thank you for your reply to us our questions.
>>>>>>>
>>>>>>>And, We have checked the value of TICK_NSEC int our system.
>>>>>>>
>>>>>>>#define TICK_NSEC ((NSEC_PER_SEC+HZ/2)/HZ)
>>>>>>>#define NSEC_PER_SEC   1000000000L
>>>>>>>HZ  250 ( Max 1000 )
>>>>>>>
>>>>>>>The value of TICK_NSEC is defined by linux kernel.
>>>>>>>And, Both NSEC_PER_SEC and HZ calculate the value of TICK_NSEC.
>>>>>>>
>>>>>>>So, The current value of TICK_NSEC is 4ms based on 250 HZ.
>>>>>>>And, If we change the value of HZ to 1000, The value of TICK_NSEC
>>>>>>>may be
>>>>>>1ms.
>>>>>>>
>>>>>>>
>>>>>>>We hope to process a task every 20us using rt_task_yield as like
>>>>>>>Xenomai
>>>>>>2.6.5.
>>>>>>>
>>>>>>>Is there any method to achieve 20us task delay using
>>>>>>>rt_task_yield or another
>>>>>>xenomai method ?
>>>>>>>And, Is there any problem to reduce the delay more less than
>>TICK_NSEC ?
>>>>>>
>>>>>>I just went through the implementation of rt_task_yield of Xeomai
>>>>>>2.6.5 and found that it is totally different from Xenomai 3.0.8.
>>>>>>If you want to yield about 20us for current RT thread ,you may try
>>>>>>call clock_nanosleep .
>>>>>>.
>>>>>>Regards
>>>>>>
>>>>>>Hongzhan Chen
>>>>>>>
>>>>>>>
>>>>>>>Really Thanks.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>This e-mail and any attachments herein may contain confidential or
>>>>>>privileged information and is for the exclusive use of the
>>>>>>intended
>>>>>>recipient(s) named above. If you are not the intended
>>>>>>recipient(s), you should not disseminate, distribute, retain, copy
>>>>>>or otherwise use any information contained herein. If you have
>>>>>>received this e-mail in error, please notify the sender
>>>>>>immediately by replying to this message and
>>>>>delete this e-mail and associated attachments.
>>>>>>Our company does not guarantee this e-mail is secure or free from
>>viruses.
>>>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>>>포함하고
>>>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>>>>용도로도 이를
>>>>>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>>>>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>>>>>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>>>>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>>>>>
>>>>>
>>>>>This e-mail and any attachments herein may contain confidential or
>>>>>privileged information and is for the exclusive use of the intended
>>>>>recipient(s) named above. If you are not the intended recipient(s),
>>>>>you should not disseminate, distribute, retain, copy or otherwise
>>>>>use any information contained herein. If you have received this
>>>>>e-mail in error, please notify the sender immediately by replying
>>>>>to this message and
>>>>delete this e-mail and associated attachments.
>>>>>Our company does not guarantee this e-mail is secure or free from
>viruses.
>>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>>포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>>용도로도 이를
>>>>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>>>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>>>>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>>>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>>>>
>>>>
>>>>This e-mail and any attachments herein may contain confidential or
>>>privileged
>>>>information and is for the exclusive use of the intended
>>>>recipient(s) named above. If you are not the intended recipient(s),
>>>>you should not disseminate, distribute, retain, copy or otherwise
>>>>use any information contained herein. If you have received this
>>>>e-mail in error, please notify the sender immediately
>>>by
>>>>replying to this message and delete this e-mail and associated attachments.
>>>>Our company does not guarantee this e-mail is secure or free from viruses.
>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>포함하고
>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>>용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로
>>>>발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을
>>알려 드립니다. 잘못
>>>수신하신
>>>>경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기
>>>>바랍니다. 협조에 감사 드립니다.
>>
>>
>>This e-mail and any attachments herein may contain confidential or
>privileged
>>information and is for the exclusive use of the intended recipient(s)
>>named above. If you are not the intended recipient(s), you should not
>>disseminate, distribute, retain, copy or otherwise use any information
>>contained herein. If you have received this e-mail in error, please
>>notify the sender immediately
>by
>>replying to this message and delete this e-mail and associated attachments.
>>Our company does not guarantee this e-mail is secure or free from viruses.
>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로
>>발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못
>수신하신
>>경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기
>>바랍니다. 협조에 감사 드립니다.


This e-mail and any attachments herein may contain confidential or privileged information and is for the exclusive use of the intended recipient(s) named above. If you are not the intended recipient(s), you should not disseminate, distribute, retain, copy or otherwise use any information contained herein. If you have received this e-mail in error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments. Our company does not guarantee this e-mail is secure or free from viruses.
이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[Chen, Hongzhan]

>-----Original Message-----
>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Sent: Tuesday, January 17, 2023 7:52 AM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim)
>수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>; 이형석(Hyungseok
>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song) 책임연구원 두산로보틱스
><changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원
>두산로보틱스 <kyungchan.son@doosan.com>; 김동주(Dongjoo Kim)
>책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>I'm really thanks for your support.
>
>
>If we apply as like below functions, The error result is not same.
>Could you explain the difference between rt_task_sleep()and

I am not familiar with alchemy skin, but from the implementation of
rt_task_sleep, we can see that it would also call clock_nanosleep when you set timeout value
but the clockid may be one of CLOCK_REALTIME and CLOCK_MONOTONIC  which depends
on your configuration, Please check rt_task_sleep(lib/alchemy/task.c) ->threadobj_sleep(lib/copperplate/threadobj.c )-> clock_nanosleep 

>clock_nanosleep() ?
>
>
>And, If our code run a cpu,
>Is there any possibility to act context switching by other process ?

Of course.

>
>
>Is the Xenomai Scheduler preemption or non- preemption ?

Xenomai scheduler support preemption but depends on how you configure schedule policy
for your threads in real case.


>
>
>While ( 1 ) {
>
>rt_task_sleep(1000000 );
>
>our code start ;
>our cod end ;
>
>}
>
>: The result is segfault by our code.
>
>
>While ( 1 ) {
>
>struct timespec ts;
>      ts.tv_sec = 0;
>      ts.tv_nsec = 1000000; /* 1ms */
>
>clock_nanosleep(CLOCK_REALTIME, 0, &ts, NULL);
>
>our code start ;
>our cod end ;
>
>}
>
>: The result is Xenomai watchdog as like below.
>   by Xenomai/cobalt: watchdog triggered CPU time limit exceeded (core
>dumped)

Watchdog triggered because Xenomai domain dominate the cpu too much time.  Please check which
Thread dominate cpu. In addition , you may check /proc/xenomai/sched/threads or /proc/xenomai/sched/stat
to find out if there is multi RT threads running at that time. If there is multi threads running , the cpu yielded by one
of rt threads by clock_nanosleep may be occupied by other RT threads which still be dominating CPU.

Regards

Hongzhan Chen

>
>
>Thanks.
>-----Original Message-----
>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>Sent: Wednesday, January 11, 2023 12:14 AM
>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim)
>수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>; 이형석(Hyungseok
>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song) 책임연구원 두산로보틱스
><changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원
>두산로보틱스 <kyungchan.son@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>주의하시기 바랍니다.
>
>CAUTION: This email is sent by an external account. Please take extra caution
>when clicking the link or opening the attachment.
>
>>-----Original Message-----
>>From: Chen, Hongzhan
>>Sent: Friday, January 6, 2023 10:36 AM
>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스
>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>두산로보틱스
>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song) 책임연구원
>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>선임연구원 두산로보틱스
>><kyungchan.son@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>
>>
>>>-----Original Message-----
>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>><dongjoo5.kim@doosan.com>
>>>Sent: Thursday, January 5, 2023 5:50 PM
>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>두산로보틱스
>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스
>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>두산로보틱스
>>><sangjoon.kim@doosan.com>;
>>이형석(Hyungseok
>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song)
>>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>;
>손경찬(Kyungchan Son) 선임연구원
>>>두산로보틱스 <kyungchan.son@doosan.com>; 김동주(Dongjoo Kim)
>책임연구원 두산로보틱스
>>><dongjoo5.kim@doosan.com>
>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>
>>>Dear Xenomai.org, Chen, Hongzhan
>>>
>>>I'm dong joo.
>>>
>>>I'm really thanks for your support.
>>>
>>>
>>>If we test a rt_mutex_create, rt_mutex_acquire, rt_mutex_release with
>>>Xenomai 2.6.5, The test result is same to Xenomai 3.
>>>
>>>Even though we disable rt_mutex_release API, the count increase
>>>increase abnormally.
>>>
>>>Is the result normal case or not ?
>>>
>>>Could you share to us the comment about the result ?
>>
>>Following is the mutex description. When the mutex is owned by current
>>task, it always can enter critical sections but just block any other
>>task per my understanding.
>>
>>Mutex services.
>>A mutex is a MUTual EXclusion object, and is useful for protecting
>>shared data structures from concurrent modifications, and implementing
>>critical sections and monitors.
>>
>>A mutex has two possible states: unlocked (not owned by any task), and
>>locked (owned by one task). A mutex can never be owned by two different
>>tasks simultaneously. A task attempting to lock a mutex that is already
>>locked by another task is blocked until the latter unlocks the mutex first.
>>
>>Xenomai mutex services enforce a priority inheritance protocol in order
>>to solve priority inversions.
>
>The implementation of rt_mutex_create set PTHREAD_MUTEX_RECURSIVE
>attribution by default for the mutex, so the same thread can have multi lock
>but avoid deadlock.
>
>Regards
>
>Hongzhan Chen
>
>>
>>Regards
>>
>>Hongzhan Chen
>>>
>>>Thanks.
>>>-----Original Message-----
>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>Sent: Thursday, January 5, 2023 6:41 PM
>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; 김동주(Dongjoo Kim)
>책임연구원
>>>두산로보틱스 <dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>두산로보틱스
>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스
>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>두산로보틱스
>>><sangjoon.kim@doosan.com>;
>>이형석(Hyungseok
>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song)
>>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>;
>손경찬(Kyungchan Son) 선임연구원
>>>두산로보틱스 <kyungchan.son@doosan.com>
>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>
>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>주의하시기 바랍니다.
>>>
>>>CAUTION: This email is sent by an external account. Please take extra
>>>caution when clicking the link or opening the attachment.
>>>
>>>>-----Original Message-----
>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>Sent: Thursday, January 5, 2023 5:25 PM
>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>두산로보틱스
>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>두산로보틱스
>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>두산로보틱스
>>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>송창우(Changwoo Song) 책임연구원
>>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>>>선임연구원 두산로보틱스
>>>><kyungchan.son@doosan.com>
>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>><dongjoo5.kim@doosan.com>
>>>>>Sent: Thursday, January 5, 2023 3:18 PM
>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>xenomai@xenomai.org
>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>;
>>>>>김세현(Sehyun Kim) 연구원
>>>>두산로보틱스
>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>두산로보틱스
>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>두산로보틱스
>>>>><sangjoon.kim@doosan.com>;
>>>>이형석(Hyungseok
>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>송창우(Changwoo Song)
>>>>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>;
>>>손경찬(Kyungchan Son) 선임연구원
>>>>>두산로보틱스 <kyungchan.son@doosan.com>; 김동주(Dongjoo Kim)
>>>책임연구원 두산로보틱스
>>>>><dongjoo5.kim@doosan.com>
>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>
>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>
>>>>>I'm dong joo.
>>>>>
>>>>>Thanks for your support.
>>>>>
>>>>>I have one more questions.
>>>>>
>>>>>Is the posix-mutex realtime mutex or not ?
>>>>
>>>>Yes, it is realtime.
>>>>
>>>>>
>>>>>And, Is there no problem to use the posix-mutex in the realtime Task ?
>>>>
>>>>No, I do not think there is problem to use posix-mutex in realttime
>>>>task. You can see that posix mutex  test already be covered in each
>>>>release as one of smokey test.
>>>>
>>>>>
>>>>>
>>>>>Finally, Is there any problem to use the rt_mutex_lock based on
>>>>>Xenomai guide?
>>>>
>>>>From Xenomai 3 , all alchemy APIs such as rt_mutex_* actually is
>>>>based on posix API, which is quite different from Xenomai 2.
>>>
>>>According to doc/asciidoc/MIGRATION.adoc,
>>>
>>>- Like +rt_mutex_inquire()+, +rt_cond_inquire()+ does not return the
>>>count
>>of
>>>waiting tasks anymore.
>>>
>>>Regards
>>>
>>>Hongzhan Chen
>>>>
>>>>Regards
>>>>
>>>>Hongzhan Chen
>>>>>
>>>>>
>>>>>Thanks.
>>>>>
>>>>>-----Original Message-----
>>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>>Sent: Thursday, January 5, 2023 4:03 PM
>>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>;
>>>>>김세현(Sehyun Kim) 연구원
>>>>두산로보틱스
>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>두산로보틱스
>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>두산로보틱스
>>>>><sangjoon.kim@doosan.com>;
>>>>이형석(Hyungseok
>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>송창우(Changwoo Song)
>>>>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>;
>>>손경찬(Kyungchan Son) 선임연구원
>>>>>두산로보틱스 <kyungchan.son@doosan.com>
>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>
>>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람
>시
>>>주의하시기 바랍니다.
>>>>>
>>>>>CAUTION: This email is sent by an external account. Please take
>>>>>extra caution when clicking the link or opening the attachment.
>>>>>
>>>>>Hi
>>>>>
>>>>>Why do not you use posix mutex like example in
>>>>>testsuite/smokey/posix- mutex/posix-mutex.c?
>>>>>
>>>>>
>>>>>Regards
>>>>>
>>>>>Hongzhan Chen
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>>>>>>Sent: Thursday, January 5, 2023 9:21 AM
>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>xenomai@xenomai.org
>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>;
>>>>>>김세현(Sehyun Kim) 연구원
>>>>>두산로보틱스
>>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>두산로보틱스
>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>>두산로보틱스
>>>>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>>>송창우(Changwoo Song) 책임연구원
>>>>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>>>>>선임연구원 두산로보틱스
>>>>>><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>>>>두산로보틱스
>>>>>><dongjoo5.kim@doosan.com>
>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>
>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>
>>>>>>I'm dong joo.
>>>>>>
>>>>>>Could you help me to solve this problem ?
>>>>>>
>>>>>>Thanks.
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>>>>>>Sent: Monday, January 2, 2023 12:10 PM
>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>xenomai@xenomai.org
>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>;
>>>>>>김세현(Sehyun Kim) 연구원
>>>>>두산로보틱스
>>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>두산로보틱스
>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>>두산로보틱스
>>>>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>>>송창우(Changwoo Song) 책임연구원
>>>>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>>>>>선임연구원 두산로보틱스
>>>>>><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>>>>두산로보틱스
>>>>>><dongjoo5.kim@doosan.com>
>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>
>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>
>>>>>>I'm dong joo.
>>>>>>
>>>>>>We have tested the API of Xenomai rt_mutex as like rt_mutex_create,
>>>>>>rt_mutex_acquire, rt_mutex_release.
>>>>>>
>>>>>>
>>>>>>If we block the rt_mutex_release,
>>>>>>The next sequence can't get a rt_mutex_acquire by the previous
>>>>>>sequence don't call rt_mutex_release before.
>>>>>>
>>>>>>So, The result of count must be 0 what we think.
>>>>>>
>>>>>>But, The result of count increase abnormally as like below. Is
>>>>>>there any problem about rt_mutex_acquire or rt_mutex_release ?
>>>>>>
>>>>>>
>>>>>>If we test the API of Xenomai rt_sem as like rt_sem_create,
>>>>>>rt_sem_p, rt_sem_v, The result of count is 0.
>>>>>>
>>>>>>
>>>>>>rt_mutex_create 0
>>>>>>task info
>>>>>>rt_mutex_acquire 0
>>>>>>Loop count: 0, Loop time: 355521102 ms rt_mutex_acquire 0 Loop count:
>>>>>>1, Loop time: 355521103 ms rt_mutex_acquire 0 Loop count: 2, Loop
>>>>>>time: 355521104 ms rt_mutex_acquire 0 Loop count: 3, Loop time:
>>>>>>355521105 ms rt_mutex_acquire 0 Loop count: 4, Loop time: 355521106
>>>>>>ms rt_mutex_acquire 0 Loop count: 5, Loop time: 355521107 ms
>>>>>>rt_mutex_acquire 0 Loop count: 6, Loop time: 355521108 ms
>>>>>>rt_mutex_acquire 0 Loop count: 7, Loop time: 355521109 ms
>>>>>>rt_mutex_acquire 0 Loop count: 8, Loop time: 355521110 ms
>>>>>>rt_mutex_acquire 0
>>>>>>
>>>>>>
>>>>>>void loop_task_proc(void *arg) {
>>>>>>
>>>>>>        int cnt = 0;
>>>>>>        int ret = 0 ;
>>>>>>
>>>>>>        RTIME tstart1;
>>>>>>
>>>>>>        RT_MUTEX            m_tMutex;
>>>>>>//      RT_SEM              m_tSemaphore;
>>>>>>        ret = rt_mutex_create(&m_tMutex, "test");
>>>>>>        rt_printf("rt_mutex_create %d\n", ret ) ;
>>>>>>
>>>>>>//      ret = rt_sem_create(&m_tSemaphore, "test", 1, S_FIFO);
>>>>>>//      rt_printf("rt_sem_create %d\n", ret ) ;
>>>>>>
>>>>>>        //Print the info
>>>>>>        rt_printf("task info \n");
>>>>>>
>>>>>>        rt_task_set_periodic(NULL, TM_NOW, LOOP_PERIOD);
>>>>>>
>>>>>>
>>>>>>        //Start the task loop
>>>>>>        while (1) {
>>>>>>        ret =   rt_mutex_acquire(&m_tMutex, TM_INFINITE );
>>>>>>        rt_printf("rt_mutex_acquire %d\n", ret ) ;
>>>>>>
>>>>>>//      rt_sem_p(&m_tSemaphore, TM_INFINITE ) ;
>>>>>>//      rt_printf("rt_sem_p %d\n", ret ) ;
>>>>>>//
>>>>>>        tstart1 = rt_timer_read () ;
>>>>>>        rt_printf("Loop count: %d, Loop time: %llu ms\n", cnt,
>>>>>>tstart1 /
>>>>>1000000 );
>>>>>>        cnt++;
>>>>>>        rt_task_wait_period(NULL);
>>>>>>
>>>>>>//      ret =           rt_mutex_release(&m_tMutex);
>>>>>>//      rt_printf("rt_mutex_release %d\n", ret ) ;
>>>>>>//      rt_sem_v(&m_tSemaphore);
>>>>>>//      rt_printf("rt_sem_v %d\n", ret ) ;
>>>>>>        }
>>>>>>}
>>>>>>
>>>>>>int main(int argc, char* argv[])
>>>>>>{
>>>>>>
>>>>>>        RT_TASK loop_task;
>>>>>>        rt_task_create(&loop_task, "basicmath_small", 0, 50, 0);
>>>>>>        rt_task_start(&loop_task, &loop_task_proc, 0);
>>>>>>        //Wait for Ctrl-C
>>>>>>        pause();
>>>>>>        return 0;
>>>>>>
>>>>>>
>>>>>>}
>>>>>>
>>>>>>Thanks.
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>>>Sent: Wednesday, October 26, 2022 11:43 AM
>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>xenomai@xenomai.org
>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>;
>>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>>두산로보틱스
>>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>>두산로보틱스
>>>>>><sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>>>>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>두산로보틱스
>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>>두산로보틱스
>>>>>><sangjoon.kim@doosan.com>; 김동주(Dongjoo
>>>>>>Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>
>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>
>>>>>>I'm dong joo.
>>>>>>
>>>>>>I have a basic question.
>>>>>>
>>>>>>If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI
>>Processor
>>>>>>CONFIG, We can't check the current cpu freq by sysnode.
>>>>>>
>>>>>>Because, sysnode of cpu freq is related to CPU_FREQ CONFIG and ACPI
>>>>>>Processor CONFIG as i know.
>>>>>>
>>>>>>
>>>>>>If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI
>>Processor
>>>>>>CONFIG, Could you expect the current cpu freq in the intel hw system ?
>>>>>>
>>>>>>Actually, The minimum cpu clock of our hw system is very low.
>>>>>>
>>>>>>If our hw system operate with minimum cpu clock always, I worry
>>>>>>about the performance of hw system.
>>>>>>
>>>>>>
>>>>>>sys/devices/system/cpu/cpu0/cpufreq# ls affected_cpus
>>>>>>cpuinfo_cur_freq  cpuinfo_min_freq
>>>freqdomain_cpus
>>>>>>scaling_available_frequencies  scaling_cur_freq  scaling_governor
>>>>>>scaling_min_freq  stats
>>>>>>bios_limit     cpuinfo_max_freq  cpuinfo_transition_latency
>related_cpus
>>>>>>scaling_available_governors    scaling_driver    scaling_max_freq
>>>>>>scaling_setspeed
>>>>>>
>>>>>>
>>>>>>Thanks.
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>>>Sent: Tuesday, October 25, 2022 5:24 PM
>>>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>;
>>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>>두산로보틱스
>>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>>두산로보틱스
>>>>>><sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>>>>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>두산로보틱스
>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>>두산로보틱스
>>>>>><sangjoon.kim@doosan.com>
>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>
>>>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람
>>시
>>>>>주의하시기 바랍니다.
>>>>>>
>>>>>>CAUTION: This email is sent by an external account. Please take
>>>>>>extra caution when clicking the link or opening the attachment.
>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>>>>>>>Sent: Tuesday, October 25, 2022 3:29 PM
>>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>>xenomai@xenomai.org
>>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>;
>>>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>>>두산로보틱스
>>>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>>>두산로보틱스
>>>>>>><sehyun2.kim@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>>>>>두산로보틱스
>>>>>>><dongjoo5.kim@doosan.com>; 이재석(Jaesuk Lee) 상무
>두산로보틱스
>>>>>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>>두산로보틱스
>>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon
>>>>>>>Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>
>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>
>>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>>
>>>>>>>I'm dong joo.
>>>>>>>
>>>>>>>After we do a aging test as like latency, We get a system hang
>>>>>>>about ten hours later.
>>>>>>>
>>>>>>>At that time, Our system don't detect usb mouse.
>>>>>>>
>>>>>>>After rebooting our system by force, there is no significative log
>>>>>>>in the kernel log or syslog.
>>>>>>>
>>>>>>>Could you help to us how to solve this issue ?
>>>>>>
>>>>>>Just as mentioned as in https://secure-
>>>>>>web.cisco.com/1ll9UQp4RYnYXuVMxAlJKaDxV1RdMZtBcG3e_jDi4TlIxD
>M
>>Tz
>>>F
>>>>>M
>>>>>>tJguJhndpS2BnNhGoAWwBP-G2UCWlarucvId1iz_ea_AU-
>>>>>>U__8Gq6ZgF285KW8SRPHKr7NeWgE4dKG8o8PGMNJ3-
>>>>>>lAB4xdptdPAk1vfJe8AL_Tt6oCEoT0OAr4RrSIjzqtmugt8EHD-
>>>>>>jvxghKHjaWu1eGDkzOYtKpcV8WhZnz1wLItIZdChYT1xlXsFTU7-
>>>>>>GnJhN2jLvMMlZgkMxzQLejJ2aB1wogBTkBIipva21mNGaSFb_sSZhX9ycwiT
>7
>>>U
>>>>M
>>>>>>UfQg5lyHCPZPEeP6/https%3A%2F%2Fxenomai.org%2Fpipermail%2Fxen
>o
>>>m
>>>>ai%
>>>>>>2F2022-April%2F047495.html
>>>>>>1. It is highly recommended to use a UART as kernel debug output.
>>>>>>2. enable CONFIG_XENO_OPT_WATCHDOG for xenomai, system will be
>>>able
>>>>>to
>>>>>>tell RT application "hangs" (infinite loop at high prio) apart from
>>>>>>real hangs/crashes.
>>>>>>
>>>>>>Regards
>>>>>>
>>>>>>Hongzhan Chen
>>>>>>>
>>>>>>>
>>>>>>>We set up our system as like below sw.
>>>>>>>
>>>>>>>1. Xubuntu 18.04 LTS 32bit
>>>>>>>
>>>>>>>2. Linux kernel 4.1.18 32bit
>>>>>>>
>>>>>>>3. Xenomai 3.0.8 32bit
>>>>>>>
>>>>>>>4. Kernel config
>>>>>>>   We refer to the xenomai page as like below.
>>>>>>>
>>>>>>>https://secure-
>>>>>>web.cisco.com/1nAW3bSL64gGRUPlQWKtShagcypkiReyVX7nhG1T-J
>>>>>>>upEWaqU-3hnCSt542V_mEwX-
>>>>>>_8HsjCaWtSuQnJ3056Yq52DypR5psiqKgrOSq6pbk6xe-tw
>>>>>>>xYZhwwm0akkU4iVwFscbrRTWdk2Ul-
>>>>>>9fU2HilSTJ8rzI8X9LIfFg2foor5t9LawggXyjgq3
>>>>>>>QqwJktjRWEhqL8gFDP2PpsmxrTgVK6NzJdcBxzyOGo_jmjjiO009l74YL2U
>5
>>K
>>>e
>>>>3
>>>>>A
>>>>>>7kc1AX7
>>>>>>>IV_t016CRGEK4QyAKRuSTqKzFm8t4flDV7eBT4m43w-o_SoFrKq-
>>>>>>AA7ZIKEYPEgpqq/http
>>>>>>>s%3A%2F%2Fsource.denx.de%2FXenomai%2Fxenomai%2F-
>>>>>>>/wikis/Configuring_For_X86_Based_Dual_Kernels#user-content-x86-
>>>>>>>processor-type
>>>>>>>
>>>>>>>Thanks.
>>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>>>>Sent: Friday, August 26, 2022 2:40 PM
>>>>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>;
>>>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>>>두산로보틱스
>>>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>>>두산로보틱스
>>>>>>><sehyun2.kim@doosan.com>
>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>
>>>>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일
>열람
>>>시
>>>>>>주의하시기 바랍니다.
>>>>>>>
>>>>>>>CAUTION: This email is sent by an external account. Please take
>>>>>>>extra caution when clicking the link or opening the attachment.
>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>>>>>>>>Sent: Friday, August 26, 2022 10:41 AM
>>>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>>>xenomai@xenomai.org
>>>>>>>>Cc: ???(Youngchul Park) ????? ??????
>>>>>>><youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ??????
>>>>>>><kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ??????
>>>>>>><sehyun2.kim@doosan.com>; ???(Dongjoo Kim) ????? ??????
>>>>>>><dongjoo5.kim@doosan.com>
>>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>>
>>>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>>>
>>>>>>>>I'm dong joo.
>>>>>>>>
>>>>>>>>Thank you for your reply to us our questions.
>>>>>>>>
>>>>>>>>And, We have checked the value of TICK_NSEC int our system.
>>>>>>>>
>>>>>>>>#define TICK_NSEC ((NSEC_PER_SEC+HZ/2)/HZ)
>>>>>>>>#define NSEC_PER_SEC   1000000000L
>>>>>>>>HZ  250 ( Max 1000 )
>>>>>>>>
>>>>>>>>The value of TICK_NSEC is defined by linux kernel.
>>>>>>>>And, Both NSEC_PER_SEC and HZ calculate the value of TICK_NSEC.
>>>>>>>>
>>>>>>>>So, The current value of TICK_NSEC is 4ms based on 250 HZ.
>>>>>>>>And, If we change the value of HZ to 1000, The value of TICK_NSEC
>>>>>>>>may be
>>>>>>>1ms.
>>>>>>>>
>>>>>>>>
>>>>>>>>We hope to process a task every 20us using rt_task_yield as like
>>>>>>>>Xenomai
>>>>>>>2.6.5.
>>>>>>>>
>>>>>>>>Is there any method to achieve 20us task delay using
>>>>>>>>rt_task_yield or another
>>>>>>>xenomai method ?
>>>>>>>>And, Is there any problem to reduce the delay more less than
>>>TICK_NSEC ?
>>>>>>>
>>>>>>>I just went through the implementation of rt_task_yield of Xeomai
>>>>>>>2.6.5 and found that it is totally different from Xenomai 3.0.8.
>>>>>>>If you want to yield about 20us for current RT thread ,you may try
>>>>>>>call clock_nanosleep .
>>>>>>>.
>>>>>>>Regards
>>>>>>>
>>>>>>>Hongzhan Chen
>>>>>>>>
>>>>>>>>
>>>>>>>>Really Thanks.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>This e-mail and any attachments herein may contain confidential or
>>>>>>>privileged information and is for the exclusive use of the
>>>>>>>intended
>>>>>>>recipient(s) named above. If you are not the intended
>>>>>>>recipient(s), you should not disseminate, distribute, retain, copy
>>>>>>>or otherwise use any information contained herein. If you have
>>>>>>>received this e-mail in error, please notify the sender
>>>>>>>immediately by replying to this message and
>>>>>>delete this e-mail and associated attachments.
>>>>>>>Our company does not guarantee this e-mail is secure or free from
>>>viruses.
>>>>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>>>>포함하고
>>>>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>>>>>용도로도 이를
>>>>>>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>>>>>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>>>>>>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>>>>>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>>>>>>
>>>>>>
>>>>>>This e-mail and any attachments herein may contain confidential or
>>>>>>privileged information and is for the exclusive use of the intended
>>>>>>recipient(s) named above. If you are not the intended recipient(s),
>>>>>>you should not disseminate, distribute, retain, copy or otherwise
>>>>>>use any information contained herein. If you have received this
>>>>>>e-mail in error, please notify the sender immediately by replying
>>>>>>to this message and
>>>>>delete this e-mail and associated attachments.
>>>>>>Our company does not guarantee this e-mail is secure or free from
>>viruses.
>>>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>>>포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>>>용도로도 이를
>>>>>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>>>>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>>>>>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>>>>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>>>>>
>>>>>
>>>>>This e-mail and any attachments herein may contain confidential or
>>>>privileged
>>>>>information and is for the exclusive use of the intended
>>>>>recipient(s) named above. If you are not the intended recipient(s),
>>>>>you should not disseminate, distribute, retain, copy or otherwise
>>>>>use any information contained herein. If you have received this
>>>>>e-mail in error, please notify the sender immediately
>>>>by
>>>>>replying to this message and delete this e-mail and associated
>attachments.
>>>>>Our company does not guarantee this e-mail is secure or free from
>viruses.
>>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>>포함하고
>>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>>>용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로
>>>>>발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을
>>>알려 드립니다. 잘못
>>>>수신하신
>>>>>경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기
>>>>>바랍니다. 협조에 감사 드립니다.
>>>
>>>
>>>This e-mail and any attachments herein may contain confidential or
>>privileged
>>>information and is for the exclusive use of the intended recipient(s)
>>>named above. If you are not the intended recipient(s), you should not
>>>disseminate, distribute, retain, copy or otherwise use any information
>>>contained herein. If you have received this e-mail in error, please
>>>notify the sender immediately
>>by
>>>replying to this message and delete this e-mail and associated attachments.
>>>Our company does not guarantee this e-mail is secure or free from viruses.
>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로
>>>발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을
>알려 드립니다. 잘못
>>수신하신
>>>경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기
>>>바랍니다. 협조에 감사 드립니다.
>
>
>This e-mail and any attachments herein may contain confidential or privileged
>information and is for the exclusive use of the intended recipient(s) named
>above. If you are not the intended recipient(s), you should not disseminate,
>distribute, retain, copy or otherwise use any information contained herein. If
>you have received this e-mail in error, please notify the sender immediately by
>replying to this message and delete this e-mail and associated attachments.
>Our company does not guarantee this e-mail is secure or free from viruses.
>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한
>수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를
>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에
>관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신
>경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기
>바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[김동주(Dongjoo Kim) 책임연구원 두산로보틱스]

Dear Xenomai.org, Chen, Hongzhan

I'm dong joo.

I'm really thanks for your support.


We set the Watchdog timeout value for 4.

Could you explain the unit of value ?
Is the value 4ms or 4s ?


[*]   Watchdog support
(4)     Watchdog timeout



Thanks
  -----Original Message-----
From: Chen, Hongzhan <hongzhan.chen@intel.com>
Sent: Tuesday, January 17, 2023 11:03 AM
To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>; xenomai@xenomai.org
Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스 <sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>; 이형석(Hyungseok Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>; 송창우(Changwoo Song) 책임연구원 두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원 두산로보틱스 <kyungchan.son@doosan.com>
Subject: RE: What causes the latency of the rt_task_yield() API?

주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시 주의하시기 바랍니다.

CAUTION: This email is sent by an external account. Please take extra caution when clicking the link or opening the attachment.

>-----Original Message-----
>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Sent: Tuesday, January 17, 2023 7:52 AM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스
><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스
><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>; 송창우(Changwoo Song) 책임연구원
>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원 두산로보틱스
><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>I'm really thanks for your support.
>
>
>If we apply as like below functions, The error result is not same.
>Could you explain the difference between rt_task_sleep()and

I am not familiar with alchemy skin, but from the implementation of rt_task_sleep, we can see that it would also call clock_nanosleep when you set timeout value but the clockid may be one of CLOCK_REALTIME and CLOCK_MONOTONIC  which depends on your configuration, Please check rt_task_sleep(lib/alchemy/task.c) ->threadobj_sleep(lib/copperplate/threadobj.c )-> clock_nanosleep

>clock_nanosleep() ?
>
>
>And, If our code run a cpu,
>Is there any possibility to act context switching by other process ?

Of course.

>
>
>Is the Xenomai Scheduler preemption or non- preemption ?

Xenomai scheduler support preemption but depends on how you configure schedule policy for your threads in real case.


>
>
>While ( 1 ) {
>
>rt_task_sleep(1000000 );
>
>our code start ;
>our cod end ;
>
>}
>
>: The result is segfault by our code.
>
>
>While ( 1 ) {
>
>struct timespec ts;
>      ts.tv_sec = 0;
>      ts.tv_nsec = 1000000; /* 1ms */
>
>clock_nanosleep(CLOCK_REALTIME, 0, &ts, NULL);
>
>our code start ;
>our cod end ;
>
>}
>
>: The result is Xenomai watchdog as like below.
>   by Xenomai/cobalt: watchdog triggered CPU time limit exceeded (core
>dumped)

Watchdog triggered because Xenomai domain dominate the cpu too much time.  Please check which Thread dominate cpu. In addition , you may check /proc/xenomai/sched/threads or /proc/xenomai/sched/stat to find out if there is multi RT threads running at that time. If there is multi threads running , the cpu yielded by one of rt threads by clock_nanosleep may be occupied by other RT threads which still be dominating CPU.

Regards

Hongzhan Chen

>
>
>Thanks.
>-----Original Message-----
>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>Sent: Wednesday, January 11, 2023 12:14 AM
>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스
><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스
><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>; 송창우(Changwoo Song) 책임연구원
>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원 두산로보틱스
><kyungchan.son@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시 주의하시기 바랍니다.
>
>CAUTION: This email is sent by an external account. Please take extra
>caution when clicking the link or opening the attachment.
>
>>-----Original Message-----
>>From: Chen, Hongzhan
>>Sent: Friday, January 6, 2023 10:36 AM
>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스
>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>두산로보틱스
>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song) 책임연구원
>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>선임연구원 두산로보틱스
>><kyungchan.son@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>
>>
>>>-----Original Message-----
>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>><dongjoo5.kim@doosan.com>
>>>Sent: Thursday, January 5, 2023 5:50 PM
>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>두산로보틱스
>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스
>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>두산로보틱스
>>><sangjoon.kim@doosan.com>;
>>이형석(Hyungseok
>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song)
>>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>;
>손경찬(Kyungchan Son) 선임연구원
>>>두산로보틱스 <kyungchan.son@doosan.com>; 김동주(Dongjoo Kim)
>책임연구원 두산로보틱스
>>><dongjoo5.kim@doosan.com>
>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>
>>>Dear Xenomai.org, Chen, Hongzhan
>>>
>>>I'm dong joo.
>>>
>>>I'm really thanks for your support.
>>>
>>>
>>>If we test a rt_mutex_create, rt_mutex_acquire, rt_mutex_release with
>>>Xenomai 2.6.5, The test result is same to Xenomai 3.
>>>
>>>Even though we disable rt_mutex_release API, the count increase
>>>increase abnormally.
>>>
>>>Is the result normal case or not ?
>>>
>>>Could you share to us the comment about the result ?
>>
>>Following is the mutex description. When the mutex is owned by current
>>task, it always can enter critical sections but just block any other
>>task per my understanding.
>>
>>Mutex services.
>>A mutex is a MUTual EXclusion object, and is useful for protecting
>>shared data structures from concurrent modifications, and implementing
>>critical sections and monitors.
>>
>>A mutex has two possible states: unlocked (not owned by any task), and
>>locked (owned by one task). A mutex can never be owned by two
>>different tasks simultaneously. A task attempting to lock a mutex that
>>is already locked by another task is blocked until the latter unlocks the mutex first.
>>
>>Xenomai mutex services enforce a priority inheritance protocol in
>>order to solve priority inversions.
>
>The implementation of rt_mutex_create set PTHREAD_MUTEX_RECURSIVE
>attribution by default for the mutex, so the same thread can have multi
>lock but avoid deadlock.
>
>Regards
>
>Hongzhan Chen
>
>>
>>Regards
>>
>>Hongzhan Chen
>>>
>>>Thanks.
>>>-----Original Message-----
>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>Sent: Thursday, January 5, 2023 6:41 PM
>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; 김동주(Dongjoo Kim)
>책임연구원
>>>두산로보틱스 <dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>두산로보틱스
>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스
>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>두산로보틱스
>>><sangjoon.kim@doosan.com>;
>>이형석(Hyungseok
>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song)
>>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>;
>손경찬(Kyungchan Son) 선임연구원
>>>두산로보틱스 <kyungchan.son@doosan.com>
>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>
>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>주의하시기 바랍니다.
>>>
>>>CAUTION: This email is sent by an external account. Please take extra
>>>caution when clicking the link or opening the attachment.
>>>
>>>>-----Original Message-----
>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>Sent: Thursday, January 5, 2023 5:25 PM
>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>;
>>>>김세현(Sehyun Kim) 연구원
>>>두산로보틱스
>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>두산로보틱스
>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>두산로보틱스
>>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>송창우(Changwoo Song) 책임연구원
>>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>>>선임연구원 두산로보틱스
>>>><kyungchan.son@doosan.com>
>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
>>>>>Sent: Thursday, January 5, 2023 3:18 PM
>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>xenomai@xenomai.org
>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>;
>>>>>김세현(Sehyun Kim) 연구원
>>>>두산로보틱스
>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>두산로보틱스
>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>두산로보틱스
>>>>><sangjoon.kim@doosan.com>;
>>>>이형석(Hyungseok
>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>송창우(Changwoo Song)
>>>>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>;
>>>손경찬(Kyungchan Son) 선임연구원
>>>>>두산로보틱스 <kyungchan.son@doosan.com>; 김동주(Dongjoo Kim)
>>>책임연구원 두산로보틱스
>>>>><dongjoo5.kim@doosan.com>
>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>
>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>
>>>>>I'm dong joo.
>>>>>
>>>>>Thanks for your support.
>>>>>
>>>>>I have one more questions.
>>>>>
>>>>>Is the posix-mutex realtime mutex or not ?
>>>>
>>>>Yes, it is realtime.
>>>>
>>>>>
>>>>>And, Is there no problem to use the posix-mutex in the realtime Task ?
>>>>
>>>>No, I do not think there is problem to use posix-mutex in realttime
>>>>task. You can see that posix mutex  test already be covered in each
>>>>release as one of smokey test.
>>>>
>>>>>
>>>>>
>>>>>Finally, Is there any problem to use the rt_mutex_lock based on
>>>>>Xenomai guide?
>>>>
>>>>From Xenomai 3 , all alchemy APIs such as rt_mutex_* actually is
>>>>based on posix API, which is quite different from Xenomai 2.
>>>
>>>According to doc/asciidoc/MIGRATION.adoc,
>>>
>>>- Like +rt_mutex_inquire()+, +rt_cond_inquire()+ does not return the
>>>count
>>of
>>>waiting tasks anymore.
>>>
>>>Regards
>>>
>>>Hongzhan Chen
>>>>
>>>>Regards
>>>>
>>>>Hongzhan Chen
>>>>>
>>>>>
>>>>>Thanks.
>>>>>
>>>>>-----Original Message-----
>>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>>Sent: Thursday, January 5, 2023 4:03 PM
>>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>;
>>>>>김세현(Sehyun Kim) 연구원
>>>>두산로보틱스
>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>두산로보틱스
>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>두산로보틱스
>>>>><sangjoon.kim@doosan.com>;
>>>>이형석(Hyungseok
>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>송창우(Changwoo Song)
>>>>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>;
>>>손경찬(Kyungchan Son) 선임연구원
>>>>>두산로보틱스 <kyungchan.son@doosan.com>
>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>
>>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람
>시
>>>주의하시기 바랍니다.
>>>>>
>>>>>CAUTION: This email is sent by an external account. Please take
>>>>>extra caution when clicking the link or opening the attachment.
>>>>>
>>>>>Hi
>>>>>
>>>>>Why do not you use posix mutex like example in
>>>>>testsuite/smokey/posix- mutex/posix-mutex.c?
>>>>>
>>>>>
>>>>>Regards
>>>>>
>>>>>Hongzhan Chen
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>>>>>>Sent: Thursday, January 5, 2023 9:21 AM
>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>xenomai@xenomai.org
>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>;
>>>>>>김세현(Sehyun Kim) 연구원
>>>>>두산로보틱스
>>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>두산로보틱스
>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>>두산로보틱스
>>>>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>>>송창우(Changwoo Song) 책임연구원
>>>>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>>>>>선임연구원 두산로보틱스
>>>>>><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>>>>두산로보틱스
>>>>>><dongjoo5.kim@doosan.com>
>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>
>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>
>>>>>>I'm dong joo.
>>>>>>
>>>>>>Could you help me to solve this problem ?
>>>>>>
>>>>>>Thanks.
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>>>>>>Sent: Monday, January 2, 2023 12:10 PM
>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>xenomai@xenomai.org
>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>;
>>>>>>김세현(Sehyun Kim) 연구원
>>>>>두산로보틱스
>>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>두산로보틱스
>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>>두산로보틱스
>>>>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>>>송창우(Changwoo Song) 책임연구원
>>>>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>>>>>선임연구원 두산로보틱스
>>>>>><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>>>>두산로보틱스
>>>>>><dongjoo5.kim@doosan.com>
>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>
>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>
>>>>>>I'm dong joo.
>>>>>>
>>>>>>We have tested the API of Xenomai rt_mutex as like
>>>>>>rt_mutex_create, rt_mutex_acquire, rt_mutex_release.
>>>>>>
>>>>>>
>>>>>>If we block the rt_mutex_release,
>>>>>>The next sequence can't get a rt_mutex_acquire by the previous
>>>>>>sequence don't call rt_mutex_release before.
>>>>>>
>>>>>>So, The result of count must be 0 what we think.
>>>>>>
>>>>>>But, The result of count increase abnormally as like below. Is
>>>>>>there any problem about rt_mutex_acquire or rt_mutex_release ?
>>>>>>
>>>>>>
>>>>>>If we test the API of Xenomai rt_sem as like rt_sem_create,
>>>>>>rt_sem_p, rt_sem_v, The result of count is 0.
>>>>>>
>>>>>>
>>>>>>rt_mutex_create 0
>>>>>>task info
>>>>>>rt_mutex_acquire 0
>>>>>>Loop count: 0, Loop time: 355521102 ms rt_mutex_acquire 0 Loop count:
>>>>>>1, Loop time: 355521103 ms rt_mutex_acquire 0 Loop count: 2, Loop
>>>>>>time: 355521104 ms rt_mutex_acquire 0 Loop count: 3, Loop time:
>>>>>>355521105 ms rt_mutex_acquire 0 Loop count: 4, Loop time:
>>>>>>355521106 ms rt_mutex_acquire 0 Loop count: 5, Loop time:
>>>>>>355521107 ms rt_mutex_acquire 0 Loop count: 6, Loop time:
>>>>>>355521108 ms rt_mutex_acquire 0 Loop count: 7, Loop time:
>>>>>>355521109 ms rt_mutex_acquire 0 Loop count: 8, Loop time:
>>>>>>355521110 ms rt_mutex_acquire 0
>>>>>>
>>>>>>
>>>>>>void loop_task_proc(void *arg) {
>>>>>>
>>>>>>        int cnt = 0;
>>>>>>        int ret = 0 ;
>>>>>>
>>>>>>        RTIME tstart1;
>>>>>>
>>>>>>        RT_MUTEX            m_tMutex;
>>>>>>//      RT_SEM              m_tSemaphore;
>>>>>>        ret = rt_mutex_create(&m_tMutex, "test");
>>>>>>        rt_printf("rt_mutex_create %d\n", ret ) ;
>>>>>>
>>>>>>//      ret = rt_sem_create(&m_tSemaphore, "test", 1, S_FIFO);
>>>>>>//      rt_printf("rt_sem_create %d\n", ret ) ;
>>>>>>
>>>>>>        //Print the info
>>>>>>        rt_printf("task info \n");
>>>>>>
>>>>>>        rt_task_set_periodic(NULL, TM_NOW, LOOP_PERIOD);
>>>>>>
>>>>>>
>>>>>>        //Start the task loop
>>>>>>        while (1) {
>>>>>>        ret =   rt_mutex_acquire(&m_tMutex, TM_INFINITE );
>>>>>>        rt_printf("rt_mutex_acquire %d\n", ret ) ;
>>>>>>
>>>>>>//      rt_sem_p(&m_tSemaphore, TM_INFINITE ) ;
>>>>>>//      rt_printf("rt_sem_p %d\n", ret ) ;
>>>>>>//
>>>>>>        tstart1 = rt_timer_read () ;
>>>>>>        rt_printf("Loop count: %d, Loop time: %llu ms\n", cnt,
>>>>>>tstart1 /
>>>>>1000000 );
>>>>>>        cnt++;
>>>>>>        rt_task_wait_period(NULL);
>>>>>>
>>>>>>//      ret =           rt_mutex_release(&m_tMutex);
>>>>>>//      rt_printf("rt_mutex_release %d\n", ret ) ;
>>>>>>//      rt_sem_v(&m_tSemaphore);
>>>>>>//      rt_printf("rt_sem_v %d\n", ret ) ;
>>>>>>        }
>>>>>>}
>>>>>>
>>>>>>int main(int argc, char* argv[])
>>>>>>{
>>>>>>
>>>>>>        RT_TASK loop_task;
>>>>>>        rt_task_create(&loop_task, "basicmath_small", 0, 50, 0);
>>>>>>        rt_task_start(&loop_task, &loop_task_proc, 0);
>>>>>>        //Wait for Ctrl-C
>>>>>>        pause();
>>>>>>        return 0;
>>>>>>
>>>>>>
>>>>>>}
>>>>>>
>>>>>>Thanks.
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>>>Sent: Wednesday, October 26, 2022 11:43 AM
>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>xenomai@xenomai.org
>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>;
>>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>>두산로보틱스
>>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>>두산로보틱스
>>>>>><sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>>>>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>두산로보틱스
>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>>두산로보틱스
>>>>>><sangjoon.kim@doosan.com>; 김동주(Dongjoo
>>>>>>Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>
>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>
>>>>>>I'm dong joo.
>>>>>>
>>>>>>I have a basic question.
>>>>>>
>>>>>>If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI
>>Processor
>>>>>>CONFIG, We can't check the current cpu freq by sysnode.
>>>>>>
>>>>>>Because, sysnode of cpu freq is related to CPU_FREQ CONFIG and
>>>>>>ACPI Processor CONFIG as i know.
>>>>>>
>>>>>>
>>>>>>If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI
>>Processor
>>>>>>CONFIG, Could you expect the current cpu freq in the intel hw system ?
>>>>>>
>>>>>>Actually, The minimum cpu clock of our hw system is very low.
>>>>>>
>>>>>>If our hw system operate with minimum cpu clock always, I worry
>>>>>>about the performance of hw system.
>>>>>>
>>>>>>
>>>>>>sys/devices/system/cpu/cpu0/cpufreq# ls affected_cpus
>>>>>>cpuinfo_cur_freq  cpuinfo_min_freq
>>>freqdomain_cpus
>>>>>>scaling_available_frequencies  scaling_cur_freq  scaling_governor
>>>>>>scaling_min_freq  stats
>>>>>>bios_limit     cpuinfo_max_freq  cpuinfo_transition_latency
>related_cpus
>>>>>>scaling_available_governors    scaling_driver    scaling_max_freq
>>>>>>scaling_setspeed
>>>>>>
>>>>>>
>>>>>>Thanks.
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>>>Sent: Tuesday, October 25, 2022 5:24 PM
>>>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>;
>>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>>두산로보틱스
>>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>>두산로보틱스
>>>>>><sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>>>>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>두산로보틱스
>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>>두산로보틱스
>>>>>><sangjoon.kim@doosan.com>
>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>
>>>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람
>>시
>>>>>주의하시기 바랍니다.
>>>>>>
>>>>>>CAUTION: This email is sent by an external account. Please take
>>>>>>extra caution when clicking the link or opening the attachment.
>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>>>>>>>Sent: Tuesday, October 25, 2022 3:29 PM
>>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>>xenomai@xenomai.org
>>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>;
>>>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>>>두산로보틱스
>>>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>>>두산로보틱스
>>>>>>><sehyun2.kim@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>>>>>두산로보틱스
>>>>>>><dongjoo5.kim@doosan.com>; 이재석(Jaesuk Lee) 상무
>두산로보틱스
>>>>>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>>두산로보틱스
>>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon
>>>>>>>Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>
>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>
>>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>>
>>>>>>>I'm dong joo.
>>>>>>>
>>>>>>>After we do a aging test as like latency, We get a system hang
>>>>>>>about ten hours later.
>>>>>>>
>>>>>>>At that time, Our system don't detect usb mouse.
>>>>>>>
>>>>>>>After rebooting our system by force, there is no significative
>>>>>>>log in the kernel log or syslog.
>>>>>>>
>>>>>>>Could you help to us how to solve this issue ?
>>>>>>
>>>>>>Just as mentioned as in https://secure-
>>>>>>web.cisco.com/1ll9UQp4RYnYXuVMxAlJKaDxV1RdMZtBcG3e_jDi4TlIxD
>M
>>Tz
>>>F
>>>>>M
>>>>>>tJguJhndpS2BnNhGoAWwBP-G2UCWlarucvId1iz_ea_AU-
>>>>>>U__8Gq6ZgF285KW8SRPHKr7NeWgE4dKG8o8PGMNJ3-
>>>>>>lAB4xdptdPAk1vfJe8AL_Tt6oCEoT0OAr4RrSIjzqtmugt8EHD-
>>>>>>jvxghKHjaWu1eGDkzOYtKpcV8WhZnz1wLItIZdChYT1xlXsFTU7-
>>>>>>GnJhN2jLvMMlZgkMxzQLejJ2aB1wogBTkBIipva21mNGaSFb_sSZhX9ycwiT
>7
>>>U
>>>>M
>>>>>>UfQg5lyHCPZPEeP6/https%3A%2F%2Fxenomai.org%2Fpipermail%2Fxen
>o
>>>m
>>>>ai%
>>>>>>2F2022-April%2F047495.html
>>>>>>1. It is highly recommended to use a UART as kernel debug output.
>>>>>>2. enable CONFIG_XENO_OPT_WATCHDOG for xenomai, system will be
>>>able
>>>>>to
>>>>>>tell RT application "hangs" (infinite loop at high prio) apart
>>>>>>from real hangs/crashes.
>>>>>>
>>>>>>Regards
>>>>>>
>>>>>>Hongzhan Chen
>>>>>>>
>>>>>>>
>>>>>>>We set up our system as like below sw.
>>>>>>>
>>>>>>>1. Xubuntu 18.04 LTS 32bit
>>>>>>>
>>>>>>>2. Linux kernel 4.1.18 32bit
>>>>>>>
>>>>>>>3. Xenomai 3.0.8 32bit
>>>>>>>
>>>>>>>4. Kernel config
>>>>>>>   We refer to the xenomai page as like below.
>>>>>>>
>>>>>>>https://secure-
>>>>>>web.cisco.com/1nAW3bSL64gGRUPlQWKtShagcypkiReyVX7nhG1T-J
>>>>>>>upEWaqU-3hnCSt542V_mEwX-
>>>>>>_8HsjCaWtSuQnJ3056Yq52DypR5psiqKgrOSq6pbk6xe-tw
>>>>>>>xYZhwwm0akkU4iVwFscbrRTWdk2Ul-
>>>>>>9fU2HilSTJ8rzI8X9LIfFg2foor5t9LawggXyjgq3
>>>>>>>QqwJktjRWEhqL8gFDP2PpsmxrTgVK6NzJdcBxzyOGo_jmjjiO009l74YL2U
>5
>>K
>>>e
>>>>3
>>>>>A
>>>>>>7kc1AX7
>>>>>>>IV_t016CRGEK4QyAKRuSTqKzFm8t4flDV7eBT4m43w-o_SoFrKq-
>>>>>>AA7ZIKEYPEgpqq/http
>>>>>>>s%3A%2F%2Fsource.denx.de%2FXenomai%2Fxenomai%2F-
>>>>>>>/wikis/Configuring_For_X86_Based_Dual_Kernels#user-content-x86-
>>>>>>>processor-type
>>>>>>>
>>>>>>>Thanks.
>>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>>>>Sent: Friday, August 26, 2022 2:40 PM
>>>>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>;
>>>>>>>xenomai@xenomai.org
>>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>;
>>>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>>>두산로보틱스
>>>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>>>두산로보틱스
>>>>>>><sehyun2.kim@doosan.com>
>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>
>>>>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일
>열람
>>>시
>>>>>>주의하시기 바랍니다.
>>>>>>>
>>>>>>>CAUTION: This email is sent by an external account. Please take
>>>>>>>extra caution when clicking the link or opening the attachment.
>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>>>>>>>>Sent: Friday, August 26, 2022 10:41 AM
>>>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>>>xenomai@xenomai.org
>>>>>>>>Cc: ???(Youngchul Park) ????? ??????
>>>>>>><youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ??????
>>>>>>><kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ??????
>>>>>>><sehyun2.kim@doosan.com>; ???(Dongjoo Kim) ????? ??????
>>>>>>><dongjoo5.kim@doosan.com>
>>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>>
>>>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>>>
>>>>>>>>I'm dong joo.
>>>>>>>>
>>>>>>>>Thank you for your reply to us our questions.
>>>>>>>>
>>>>>>>>And, We have checked the value of TICK_NSEC int our system.
>>>>>>>>
>>>>>>>>#define TICK_NSEC ((NSEC_PER_SEC+HZ/2)/HZ)
>>>>>>>>#define NSEC_PER_SEC   1000000000L
>>>>>>>>HZ  250 ( Max 1000 )
>>>>>>>>
>>>>>>>>The value of TICK_NSEC is defined by linux kernel.
>>>>>>>>And, Both NSEC_PER_SEC and HZ calculate the value of TICK_NSEC.
>>>>>>>>
>>>>>>>>So, The current value of TICK_NSEC is 4ms based on 250 HZ.
>>>>>>>>And, If we change the value of HZ to 1000, The value of
>>>>>>>>TICK_NSEC may be
>>>>>>>1ms.
>>>>>>>>
>>>>>>>>
>>>>>>>>We hope to process a task every 20us using rt_task_yield as like
>>>>>>>>Xenomai
>>>>>>>2.6.5.
>>>>>>>>
>>>>>>>>Is there any method to achieve 20us task delay using
>>>>>>>>rt_task_yield or another
>>>>>>>xenomai method ?
>>>>>>>>And, Is there any problem to reduce the delay more less than
>>>TICK_NSEC ?
>>>>>>>
>>>>>>>I just went through the implementation of rt_task_yield of Xeomai
>>>>>>>2.6.5 and found that it is totally different from Xenomai 3.0.8.
>>>>>>>If you want to yield about 20us for current RT thread ,you may
>>>>>>>try call clock_nanosleep .
>>>>>>>.
>>>>>>>Regards
>>>>>>>
>>>>>>>Hongzhan Chen
>>>>>>>>
>>>>>>>>
>>>>>>>>Really Thanks.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>This e-mail and any attachments herein may contain confidential
>>>>>>>or privileged information and is for the exclusive use of the
>>>>>>>intended
>>>>>>>recipient(s) named above. If you are not the intended
>>>>>>>recipient(s), you should not disseminate, distribute, retain,
>>>>>>>copy or otherwise use any information contained herein. If you
>>>>>>>have received this e-mail in error, please notify the sender
>>>>>>>immediately by replying to this message and
>>>>>>delete this e-mail and associated attachments.
>>>>>>>Our company does not guarantee this e-mail is secure or free from
>>>viruses.
>>>>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>>>>포함하고
>>>>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>>>>>용도로도 이를
>>>>>>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>>>>>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>>>>>>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>>>>>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>>>>>>
>>>>>>
>>>>>>This e-mail and any attachments herein may contain confidential or
>>>>>>privileged information and is for the exclusive use of the
>>>>>>intended
>>>>>>recipient(s) named above. If you are not the intended
>>>>>>recipient(s), you should not disseminate, distribute, retain, copy
>>>>>>or otherwise use any information contained herein. If you have
>>>>>>received this e-mail in error, please notify the sender
>>>>>>immediately by replying to this message and
>>>>>delete this e-mail and associated attachments.
>>>>>>Our company does not guarantee this e-mail is secure or free from
>>viruses.
>>>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>>>포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>>>용도로도 이를
>>>>>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>>>>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>>>>>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>>>>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>>>>>
>>>>>
>>>>>This e-mail and any attachments herein may contain confidential or
>>>>privileged
>>>>>information and is for the exclusive use of the intended
>>>>>recipient(s) named above. If you are not the intended recipient(s),
>>>>>you should not disseminate, distribute, retain, copy or otherwise
>>>>>use any information contained herein. If you have received this
>>>>>e-mail in error, please notify the sender immediately
>>>>by
>>>>>replying to this message and delete this e-mail and associated
>attachments.
>>>>>Our company does not guarantee this e-mail is secure or free from
>viruses.
>>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>>포함하고
>>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>>>용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로
>>>>>발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을
>>>알려 드립니다. 잘못
>>>>수신하신
>>>>>경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기
>>>>>바랍니다. 협조에 감사 드립니다.
>>>
>>>
>>>This e-mail and any attachments herein may contain confidential or
>>privileged
>>>information and is for the exclusive use of the intended recipient(s)
>>>named above. If you are not the intended recipient(s), you should not
>>>disseminate, distribute, retain, copy or otherwise use any
>>>information contained herein. If you have received this e-mail in
>>>error, please notify the sender immediately
>>by
>>>replying to this message and delete this e-mail and associated attachments.
>>>Our company does not guarantee this e-mail is secure or free from viruses.
>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로
>>>발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을
>알려 드립니다. 잘못
>>수신하신
>>>경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기
>>>바랍니다. 협조에 감사 드립니다.
>
>
>This e-mail and any attachments herein may contain confidential or
>privileged information and is for the exclusive use of the intended
>recipient(s) named above. If you are not the intended recipient(s), you
>should not disseminate, distribute, retain, copy or otherwise use any
>information contained herein. If you have received this e-mail in
>error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments.
>Our company does not guarantee this e-mail is secure or free from viruses.
>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한
>수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.


This e-mail and any attachments herein may contain confidential or privileged information and is for the exclusive use of the intended recipient(s) named above. If you are not the intended recipient(s), you should not disseminate, distribute, retain, copy or otherwise use any information contained herein. If you have received this e-mail in error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments. Our company does not guarantee this e-mail is secure or free from viruses.
이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[김동주(Dongjoo Kim) 책임연구원 두산로보틱스]

Dear Xenomai.org, Chen, Hongzhan

I'm dong joo.

I'm really thanks for your support.


We set the Watchdog timeout value for 4.

Could you explain the unit of value ?
Is the value 4ms or 4s ?


[*]   Watchdog support
(4)     Watchdog timeout


Thanks

-----Original Message-----
From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
Sent: Tuesday, January 17, 2023 2:46 PM
To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스 <sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>; 이형석(Hyungseok Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>; 송창우(Changwoo Song) 책임연구원 두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원 두산로보틱스 <kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
Subject: RE: What causes the latency of the rt_task_yield() API?

Dear Xenomai.org, Chen, Hongzhan

I'm dong joo.

I'm really thanks for your support.


We set the Watchdog timeout value for 4.

Could you explain the unit of value ?
Is the value 4ms or 4s ?


[*]   Watchdog support
(4)     Watchdog timeout



Thanks
  -----Original Message-----
From: Chen, Hongzhan <hongzhan.chen@intel.com>
Sent: Tuesday, January 17, 2023 11:03 AM
To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>; xenomai@xenomai.org
Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스 <sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>; 이형석(Hyungseok Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>; 송창우(Changwoo Song) 책임연구원 두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원 두산로보틱스 <kyungchan.son@doosan.com>
Subject: RE: What causes the latency of the rt_task_yield() API?

주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시 주의하시기 바랍니다.

CAUTION: This email is sent by an external account. Please take extra caution when clicking the link or opening the attachment.

>-----Original Message-----
>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Sent: Tuesday, January 17, 2023 7:52 AM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스
><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스
><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>; 송창우(Changwoo Song) 책임연구원
>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원 두산로보틱스
><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>I'm really thanks for your support.
>
>
>If we apply as like below functions, The error result is not same.
>Could you explain the difference between rt_task_sleep()and

I am not familiar with alchemy skin, but from the implementation of rt_task_sleep, we can see that it would also call clock_nanosleep when you set timeout value but the clockid may be one of CLOCK_REALTIME and CLOCK_MONOTONIC  which depends on your configuration, Please check rt_task_sleep(lib/alchemy/task.c) ->threadobj_sleep(lib/copperplate/threadobj.c )-> clock_nanosleep

>clock_nanosleep() ?
>
>
>And, If our code run a cpu,
>Is there any possibility to act context switching by other process ?

Of course.

>
>
>Is the Xenomai Scheduler preemption or non- preemption ?

Xenomai scheduler support preemption but depends on how you configure schedule policy for your threads in real case.


>
>
>While ( 1 ) {
>
>rt_task_sleep(1000000 );
>
>our code start ;
>our cod end ;
>
>}
>
>: The result is segfault by our code.
>
>
>While ( 1 ) {
>
>struct timespec ts;
>      ts.tv_sec = 0;
>      ts.tv_nsec = 1000000; /* 1ms */
>
>clock_nanosleep(CLOCK_REALTIME, 0, &ts, NULL);
>
>our code start ;
>our cod end ;
>
>}
>
>: The result is Xenomai watchdog as like below.
>   by Xenomai/cobalt: watchdog triggered CPU time limit exceeded (core
>dumped)

Watchdog triggered because Xenomai domain dominate the cpu too much time.  Please check which Thread dominate cpu. In addition , you may check /proc/xenomai/sched/threads or /proc/xenomai/sched/stat to find out if there is multi RT threads running at that time. If there is multi threads running , the cpu yielded by one of rt threads by clock_nanosleep may be occupied by other RT threads which still be dominating CPU.

Regards

Hongzhan Chen

>
>
>Thanks.
>-----Original Message-----
>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>Sent: Wednesday, January 11, 2023 12:14 AM
>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스
><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스
><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>; 송창우(Changwoo Song) 책임연구원
>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원 두산로보틱스
><kyungchan.son@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시 주의하시기 바랍니다.
>
>CAUTION: This email is sent by an external account. Please take extra
>caution when clicking the link or opening the attachment.
>
>>-----Original Message-----
>>From: Chen, Hongzhan
>>Sent: Friday, January 6, 2023 10:36 AM
>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스
>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>두산로보틱스
>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song) 책임연구원
>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>선임연구원 두산로보틱스
>><kyungchan.son@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>
>>
>>>-----Original Message-----
>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>><dongjoo5.kim@doosan.com>
>>>Sent: Thursday, January 5, 2023 5:50 PM
>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>두산로보틱스
>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스
>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>두산로보틱스
>>><sangjoon.kim@doosan.com>;
>>이형석(Hyungseok
>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song)
>>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>;
>손경찬(Kyungchan Son) 선임연구원
>>>두산로보틱스 <kyungchan.son@doosan.com>; 김동주(Dongjoo Kim)
>책임연구원 두산로보틱스
>>><dongjoo5.kim@doosan.com>
>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>
>>>Dear Xenomai.org, Chen, Hongzhan
>>>
>>>I'm dong joo.
>>>
>>>I'm really thanks for your support.
>>>
>>>
>>>If we test a rt_mutex_create, rt_mutex_acquire, rt_mutex_release with
>>>Xenomai 2.6.5, The test result is same to Xenomai 3.
>>>
>>>Even though we disable rt_mutex_release API, the count increase
>>>increase abnormally.
>>>
>>>Is the result normal case or not ?
>>>
>>>Could you share to us the comment about the result ?
>>
>>Following is the mutex description. When the mutex is owned by current
>>task, it always can enter critical sections but just block any other
>>task per my understanding.
>>
>>Mutex services.
>>A mutex is a MUTual EXclusion object, and is useful for protecting
>>shared data structures from concurrent modifications, and implementing
>>critical sections and monitors.
>>
>>A mutex has two possible states: unlocked (not owned by any task), and
>>locked (owned by one task). A mutex can never be owned by two
>>different tasks simultaneously. A task attempting to lock a mutex that
>>is already locked by another task is blocked until the latter unlocks the mutex first.
>>
>>Xenomai mutex services enforce a priority inheritance protocol in
>>order to solve priority inversions.
>
>The implementation of rt_mutex_create set PTHREAD_MUTEX_RECURSIVE
>attribution by default for the mutex, so the same thread can have multi
>lock but avoid deadlock.
>
>Regards
>
>Hongzhan Chen
>
>>
>>Regards
>>
>>Hongzhan Chen
>>>
>>>Thanks.
>>>-----Original Message-----
>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>Sent: Thursday, January 5, 2023 6:41 PM
>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; 김동주(Dongjoo Kim)
>책임연구원
>>>두산로보틱스 <dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>두산로보틱스
>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스
>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>두산로보틱스
>>><sangjoon.kim@doosan.com>;
>>이형석(Hyungseok
>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song)
>>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>;
>손경찬(Kyungchan Son) 선임연구원
>>>두산로보틱스 <kyungchan.son@doosan.com>
>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>
>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>주의하시기 바랍니다.
>>>
>>>CAUTION: This email is sent by an external account. Please take extra
>>>caution when clicking the link or opening the attachment.
>>>
>>>>-----Original Message-----
>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>Sent: Thursday, January 5, 2023 5:25 PM
>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>;
>>>>김세현(Sehyun Kim) 연구원
>>>두산로보틱스
>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>두산로보틱스
>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>두산로보틱스
>>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>송창우(Changwoo Song) 책임연구원
>>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>>>선임연구원 두산로보틱스
>>>><kyungchan.son@doosan.com>
>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
>>>>>Sent: Thursday, January 5, 2023 3:18 PM
>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>xenomai@xenomai.org
>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>;
>>>>>김세현(Sehyun Kim) 연구원
>>>>두산로보틱스
>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>두산로보틱스
>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>두산로보틱스
>>>>><sangjoon.kim@doosan.com>;
>>>>이형석(Hyungseok
>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>송창우(Changwoo Song)
>>>>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>;
>>>손경찬(Kyungchan Son) 선임연구원
>>>>>두산로보틱스 <kyungchan.son@doosan.com>; 김동주(Dongjoo Kim)
>>>책임연구원 두산로보틱스
>>>>><dongjoo5.kim@doosan.com>
>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>
>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>
>>>>>I'm dong joo.
>>>>>
>>>>>Thanks for your support.
>>>>>
>>>>>I have one more questions.
>>>>>
>>>>>Is the posix-mutex realtime mutex or not ?
>>>>
>>>>Yes, it is realtime.
>>>>
>>>>>
>>>>>And, Is there no problem to use the posix-mutex in the realtime Task ?
>>>>
>>>>No, I do not think there is problem to use posix-mutex in realttime
>>>>task. You can see that posix mutex  test already be covered in each
>>>>release as one of smokey test.
>>>>
>>>>>
>>>>>
>>>>>Finally, Is there any problem to use the rt_mutex_lock based on
>>>>>Xenomai guide?
>>>>
>>>>From Xenomai 3 , all alchemy APIs such as rt_mutex_* actually is
>>>>based on posix API, which is quite different from Xenomai 2.
>>>
>>>According to doc/asciidoc/MIGRATION.adoc,
>>>
>>>- Like +rt_mutex_inquire()+, +rt_cond_inquire()+ does not return the
>>>count
>>of
>>>waiting tasks anymore.
>>>
>>>Regards
>>>
>>>Hongzhan Chen
>>>>
>>>>Regards
>>>>
>>>>Hongzhan Chen
>>>>>
>>>>>
>>>>>Thanks.
>>>>>
>>>>>-----Original Message-----
>>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>>Sent: Thursday, January 5, 2023 4:03 PM
>>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>;
>>>>>김세현(Sehyun Kim) 연구원
>>>>두산로보틱스
>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>두산로보틱스
>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>두산로보틱스
>>>>><sangjoon.kim@doosan.com>;
>>>>이형석(Hyungseok
>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>송창우(Changwoo Song)
>>>>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>;
>>>손경찬(Kyungchan Son) 선임연구원
>>>>>두산로보틱스 <kyungchan.son@doosan.com>
>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>
>>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람
>시
>>>주의하시기 바랍니다.
>>>>>
>>>>>CAUTION: This email is sent by an external account. Please take
>>>>>extra caution when clicking the link or opening the attachment.
>>>>>
>>>>>Hi
>>>>>
>>>>>Why do not you use posix mutex like example in
>>>>>testsuite/smokey/posix- mutex/posix-mutex.c?
>>>>>
>>>>>
>>>>>Regards
>>>>>
>>>>>Hongzhan Chen
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>>>>>>Sent: Thursday, January 5, 2023 9:21 AM
>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>xenomai@xenomai.org
>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>;
>>>>>>김세현(Sehyun Kim) 연구원
>>>>>두산로보틱스
>>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>두산로보틱스
>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>>두산로보틱스
>>>>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>>>송창우(Changwoo Song) 책임연구원
>>>>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>>>>>선임연구원 두산로보틱스
>>>>>><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>>>>두산로보틱스
>>>>>><dongjoo5.kim@doosan.com>
>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>
>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>
>>>>>>I'm dong joo.
>>>>>>
>>>>>>Could you help me to solve this problem ?
>>>>>>
>>>>>>Thanks.
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>>>>>>Sent: Monday, January 2, 2023 12:10 PM
>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>xenomai@xenomai.org
>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>;
>>>>>>김세현(Sehyun Kim) 연구원
>>>>>두산로보틱스
>>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>두산로보틱스
>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>>두산로보틱스
>>>>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>>>송창우(Changwoo Song) 책임연구원
>>>>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>>>>>선임연구원 두산로보틱스
>>>>>><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>>>>두산로보틱스
>>>>>><dongjoo5.kim@doosan.com>
>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>
>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>
>>>>>>I'm dong joo.
>>>>>>
>>>>>>We have tested the API of Xenomai rt_mutex as like
>>>>>>rt_mutex_create, rt_mutex_acquire, rt_mutex_release.
>>>>>>
>>>>>>
>>>>>>If we block the rt_mutex_release,
>>>>>>The next sequence can't get a rt_mutex_acquire by the previous
>>>>>>sequence don't call rt_mutex_release before.
>>>>>>
>>>>>>So, The result of count must be 0 what we think.
>>>>>>
>>>>>>But, The result of count increase abnormally as like below. Is
>>>>>>there any problem about rt_mutex_acquire or rt_mutex_release ?
>>>>>>
>>>>>>
>>>>>>If we test the API of Xenomai rt_sem as like rt_sem_create,
>>>>>>rt_sem_p, rt_sem_v, The result of count is 0.
>>>>>>
>>>>>>
>>>>>>rt_mutex_create 0
>>>>>>task info
>>>>>>rt_mutex_acquire 0
>>>>>>Loop count: 0, Loop time: 355521102 ms rt_mutex_acquire 0 Loop count:
>>>>>>1, Loop time: 355521103 ms rt_mutex_acquire 0 Loop count: 2, Loop
>>>>>>time: 355521104 ms rt_mutex_acquire 0 Loop count: 3, Loop time:
>>>>>>355521105 ms rt_mutex_acquire 0 Loop count: 4, Loop time:
>>>>>>355521106 ms rt_mutex_acquire 0 Loop count: 5, Loop time:
>>>>>>355521107 ms rt_mutex_acquire 0 Loop count: 6, Loop time:
>>>>>>355521108 ms rt_mutex_acquire 0 Loop count: 7, Loop time:
>>>>>>355521109 ms rt_mutex_acquire 0 Loop count: 8, Loop time:
>>>>>>355521110 ms rt_mutex_acquire 0
>>>>>>
>>>>>>
>>>>>>void loop_task_proc(void *arg) {
>>>>>>
>>>>>>        int cnt = 0;
>>>>>>        int ret = 0 ;
>>>>>>
>>>>>>        RTIME tstart1;
>>>>>>
>>>>>>        RT_MUTEX            m_tMutex;
>>>>>>//      RT_SEM              m_tSemaphore;
>>>>>>        ret = rt_mutex_create(&m_tMutex, "test");
>>>>>>        rt_printf("rt_mutex_create %d\n", ret ) ;
>>>>>>
>>>>>>//      ret = rt_sem_create(&m_tSemaphore, "test", 1, S_FIFO);
>>>>>>//      rt_printf("rt_sem_create %d\n", ret ) ;
>>>>>>
>>>>>>        //Print the info
>>>>>>        rt_printf("task info \n");
>>>>>>
>>>>>>        rt_task_set_periodic(NULL, TM_NOW, LOOP_PERIOD);
>>>>>>
>>>>>>
>>>>>>        //Start the task loop
>>>>>>        while (1) {
>>>>>>        ret =   rt_mutex_acquire(&m_tMutex, TM_INFINITE );
>>>>>>        rt_printf("rt_mutex_acquire %d\n", ret ) ;
>>>>>>
>>>>>>//      rt_sem_p(&m_tSemaphore, TM_INFINITE ) ;
>>>>>>//      rt_printf("rt_sem_p %d\n", ret ) ;
>>>>>>//
>>>>>>        tstart1 = rt_timer_read () ;
>>>>>>        rt_printf("Loop count: %d, Loop time: %llu ms\n", cnt,
>>>>>>tstart1 /
>>>>>1000000 );
>>>>>>        cnt++;
>>>>>>        rt_task_wait_period(NULL);
>>>>>>
>>>>>>//      ret =           rt_mutex_release(&m_tMutex);
>>>>>>//      rt_printf("rt_mutex_release %d\n", ret ) ;
>>>>>>//      rt_sem_v(&m_tSemaphore);
>>>>>>//      rt_printf("rt_sem_v %d\n", ret ) ;
>>>>>>        }
>>>>>>}
>>>>>>
>>>>>>int main(int argc, char* argv[])
>>>>>>{
>>>>>>
>>>>>>        RT_TASK loop_task;
>>>>>>        rt_task_create(&loop_task, "basicmath_small", 0, 50, 0);
>>>>>>        rt_task_start(&loop_task, &loop_task_proc, 0);
>>>>>>        //Wait for Ctrl-C
>>>>>>        pause();
>>>>>>        return 0;
>>>>>>
>>>>>>
>>>>>>}
>>>>>>
>>>>>>Thanks.
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>>>Sent: Wednesday, October 26, 2022 11:43 AM
>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>xenomai@xenomai.org
>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>;
>>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>>두산로보틱스
>>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>>두산로보틱스
>>>>>><sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>>>>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>두산로보틱스
>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>>두산로보틱스
>>>>>><sangjoon.kim@doosan.com>; 김동주(Dongjoo
>>>>>>Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>
>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>
>>>>>>I'm dong joo.
>>>>>>
>>>>>>I have a basic question.
>>>>>>
>>>>>>If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI
>>Processor
>>>>>>CONFIG, We can't check the current cpu freq by sysnode.
>>>>>>
>>>>>>Because, sysnode of cpu freq is related to CPU_FREQ CONFIG and
>>>>>>ACPI Processor CONFIG as i know.
>>>>>>
>>>>>>
>>>>>>If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI
>>Processor
>>>>>>CONFIG, Could you expect the current cpu freq in the intel hw system ?
>>>>>>
>>>>>>Actually, The minimum cpu clock of our hw system is very low.
>>>>>>
>>>>>>If our hw system operate with minimum cpu clock always, I worry
>>>>>>about the performance of hw system.
>>>>>>
>>>>>>
>>>>>>sys/devices/system/cpu/cpu0/cpufreq# ls affected_cpus
>>>>>>cpuinfo_cur_freq  cpuinfo_min_freq
>>>freqdomain_cpus
>>>>>>scaling_available_frequencies  scaling_cur_freq  scaling_governor
>>>>>>scaling_min_freq  stats
>>>>>>bios_limit     cpuinfo_max_freq  cpuinfo_transition_latency
>related_cpus
>>>>>>scaling_available_governors    scaling_driver    scaling_max_freq
>>>>>>scaling_setspeed
>>>>>>
>>>>>>
>>>>>>Thanks.
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>>>Sent: Tuesday, October 25, 2022 5:24 PM
>>>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>;
>>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>>두산로보틱스
>>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>>두산로보틱스
>>>>>><sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>>>>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>두산로보틱스
>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>>두산로보틱스
>>>>>><sangjoon.kim@doosan.com>
>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>
>>>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람
>>시
>>>>>주의하시기 바랍니다.
>>>>>>
>>>>>>CAUTION: This email is sent by an external account. Please take
>>>>>>extra caution when clicking the link or opening the attachment.
>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>>>>>>>Sent: Tuesday, October 25, 2022 3:29 PM
>>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>>xenomai@xenomai.org
>>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>;
>>>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>>>두산로보틱스
>>>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>>>두산로보틱스
>>>>>>><sehyun2.kim@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>>>>>두산로보틱스
>>>>>>><dongjoo5.kim@doosan.com>; 이재석(Jaesuk Lee) 상무
>두산로보틱스
>>>>>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>>두산로보틱스
>>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon
>>>>>>>Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>
>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>
>>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>>
>>>>>>>I'm dong joo.
>>>>>>>
>>>>>>>After we do a aging test as like latency, We get a system hang
>>>>>>>about ten hours later.
>>>>>>>
>>>>>>>At that time, Our system don't detect usb mouse.
>>>>>>>
>>>>>>>After rebooting our system by force, there is no significative
>>>>>>>log in the kernel log or syslog.
>>>>>>>
>>>>>>>Could you help to us how to solve this issue ?
>>>>>>
>>>>>>Just as mentioned as in https://secure-
>>>>>>web.cisco.com/1ll9UQp4RYnYXuVMxAlJKaDxV1RdMZtBcG3e_jDi4TlIxD
>M
>>Tz
>>>F
>>>>>M
>>>>>>tJguJhndpS2BnNhGoAWwBP-G2UCWlarucvId1iz_ea_AU-
>>>>>>U__8Gq6ZgF285KW8SRPHKr7NeWgE4dKG8o8PGMNJ3-
>>>>>>lAB4xdptdPAk1vfJe8AL_Tt6oCEoT0OAr4RrSIjzqtmugt8EHD-
>>>>>>jvxghKHjaWu1eGDkzOYtKpcV8WhZnz1wLItIZdChYT1xlXsFTU7-
>>>>>>GnJhN2jLvMMlZgkMxzQLejJ2aB1wogBTkBIipva21mNGaSFb_sSZhX9ycwiT
>7
>>>U
>>>>M
>>>>>>UfQg5lyHCPZPEeP6/https%3A%2F%2Fxenomai.org%2Fpipermail%2Fxen
>o
>>>m
>>>>ai%
>>>>>>2F2022-April%2F047495.html
>>>>>>1. It is highly recommended to use a UART as kernel debug output.
>>>>>>2. enable CONFIG_XENO_OPT_WATCHDOG for xenomai, system will be
>>>able
>>>>>to
>>>>>>tell RT application "hangs" (infinite loop at high prio) apart
>>>>>>from real hangs/crashes.
>>>>>>
>>>>>>Regards
>>>>>>
>>>>>>Hongzhan Chen
>>>>>>>
>>>>>>>
>>>>>>>We set up our system as like below sw.
>>>>>>>
>>>>>>>1. Xubuntu 18.04 LTS 32bit
>>>>>>>
>>>>>>>2. Linux kernel 4.1.18 32bit
>>>>>>>
>>>>>>>3. Xenomai 3.0.8 32bit
>>>>>>>
>>>>>>>4. Kernel config
>>>>>>>   We refer to the xenomai page as like below.
>>>>>>>
>>>>>>>https://secure-
>>>>>>web.cisco.com/1nAW3bSL64gGRUPlQWKtShagcypkiReyVX7nhG1T-J
>>>>>>>upEWaqU-3hnCSt542V_mEwX-
>>>>>>_8HsjCaWtSuQnJ3056Yq52DypR5psiqKgrOSq6pbk6xe-tw
>>>>>>>xYZhwwm0akkU4iVwFscbrRTWdk2Ul-
>>>>>>9fU2HilSTJ8rzI8X9LIfFg2foor5t9LawggXyjgq3
>>>>>>>QqwJktjRWEhqL8gFDP2PpsmxrTgVK6NzJdcBxzyOGo_jmjjiO009l74YL2U
>5
>>K
>>>e
>>>>3
>>>>>A
>>>>>>7kc1AX7
>>>>>>>IV_t016CRGEK4QyAKRuSTqKzFm8t4flDV7eBT4m43w-o_SoFrKq-
>>>>>>AA7ZIKEYPEgpqq/http
>>>>>>>s%3A%2F%2Fsource.denx.de%2FXenomai%2Fxenomai%2F-
>>>>>>>/wikis/Configuring_For_X86_Based_Dual_Kernels#user-content-x86-
>>>>>>>processor-type
>>>>>>>
>>>>>>>Thanks.
>>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>>>>Sent: Friday, August 26, 2022 2:40 PM
>>>>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>;
>>>>>>>xenomai@xenomai.org
>>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>;
>>>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>>>두산로보틱스
>>>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>>>두산로보틱스
>>>>>>><sehyun2.kim@doosan.com>
>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>
>>>>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일
>열람
>>>시
>>>>>>주의하시기 바랍니다.
>>>>>>>
>>>>>>>CAUTION: This email is sent by an external account. Please take
>>>>>>>extra caution when clicking the link or opening the attachment.
>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>>>>>>>>Sent: Friday, August 26, 2022 10:41 AM
>>>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>>>xenomai@xenomai.org
>>>>>>>>Cc: ???(Youngchul Park) ????? ??????
>>>>>>><youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ??????
>>>>>>><kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ??????
>>>>>>><sehyun2.kim@doosan.com>; ???(Dongjoo Kim) ????? ??????
>>>>>>><dongjoo5.kim@doosan.com>
>>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>>
>>>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>>>
>>>>>>>>I'm dong joo.
>>>>>>>>
>>>>>>>>Thank you for your reply to us our questions.
>>>>>>>>
>>>>>>>>And, We have checked the value of TICK_NSEC int our system.
>>>>>>>>
>>>>>>>>#define TICK_NSEC ((NSEC_PER_SEC+HZ/2)/HZ)
>>>>>>>>#define NSEC_PER_SEC   1000000000L
>>>>>>>>HZ  250 ( Max 1000 )
>>>>>>>>
>>>>>>>>The value of TICK_NSEC is defined by linux kernel.
>>>>>>>>And, Both NSEC_PER_SEC and HZ calculate the value of TICK_NSEC.
>>>>>>>>
>>>>>>>>So, The current value of TICK_NSEC is 4ms based on 250 HZ.
>>>>>>>>And, If we change the value of HZ to 1000, The value of
>>>>>>>>TICK_NSEC may be
>>>>>>>1ms.
>>>>>>>>
>>>>>>>>
>>>>>>>>We hope to process a task every 20us using rt_task_yield as like
>>>>>>>>Xenomai
>>>>>>>2.6.5.
>>>>>>>>
>>>>>>>>Is there any method to achieve 20us task delay using
>>>>>>>>rt_task_yield or another
>>>>>>>xenomai method ?
>>>>>>>>And, Is there any problem to reduce the delay more less than
>>>TICK_NSEC ?
>>>>>>>
>>>>>>>I just went through the implementation of rt_task_yield of Xeomai
>>>>>>>2.6.5 and found that it is totally different from Xenomai 3.0.8.
>>>>>>>If you want to yield about 20us for current RT thread ,you may
>>>>>>>try call clock_nanosleep .
>>>>>>>.
>>>>>>>Regards
>>>>>>>
>>>>>>>Hongzhan Chen
>>>>>>>>
>>>>>>>>
>>>>>>>>Really Thanks.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>This e-mail and any attachments herein may contain confidential
>>>>>>>or privileged information and is for the exclusive use of the
>>>>>>>intended
>>>>>>>recipient(s) named above. If you are not the intended
>>>>>>>recipient(s), you should not disseminate, distribute, retain,
>>>>>>>copy or otherwise use any information contained herein. If you
>>>>>>>have received this e-mail in error, please notify the sender
>>>>>>>immediately by replying to this message and
>>>>>>delete this e-mail and associated attachments.
>>>>>>>Our company does not guarantee this e-mail is secure or free from
>>>viruses.
>>>>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>>>>포함하고
>>>>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>>>>>용도로도 이를
>>>>>>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>>>>>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>>>>>>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>>>>>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>>>>>>
>>>>>>
>>>>>>This e-mail and any attachments herein may contain confidential or
>>>>>>privileged information and is for the exclusive use of the
>>>>>>intended
>>>>>>recipient(s) named above. If you are not the intended
>>>>>>recipient(s), you should not disseminate, distribute, retain, copy
>>>>>>or otherwise use any information contained herein. If you have
>>>>>>received this e-mail in error, please notify the sender
>>>>>>immediately by replying to this message and
>>>>>delete this e-mail and associated attachments.
>>>>>>Our company does not guarantee this e-mail is secure or free from
>>viruses.
>>>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>>>포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>>>용도로도 이를
>>>>>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>>>>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>>>>>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>>>>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>>>>>
>>>>>
>>>>>This e-mail and any attachments herein may contain confidential or
>>>>privileged
>>>>>information and is for the exclusive use of the intended
>>>>>recipient(s) named above. If you are not the intended recipient(s),
>>>>>you should not disseminate, distribute, retain, copy or otherwise
>>>>>use any information contained herein. If you have received this
>>>>>e-mail in error, please notify the sender immediately
>>>>by
>>>>>replying to this message and delete this e-mail and associated
>attachments.
>>>>>Our company does not guarantee this e-mail is secure or free from
>viruses.
>>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>>포함하고
>>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>>>용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로
>>>>>발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을
>>>알려 드립니다. 잘못
>>>>수신하신
>>>>>경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기
>>>>>바랍니다. 협조에 감사 드립니다.
>>>
>>>
>>>This e-mail and any attachments herein may contain confidential or
>>privileged
>>>information and is for the exclusive use of the intended recipient(s)
>>>named above. If you are not the intended recipient(s), you should not
>>>disseminate, distribute, retain, copy or otherwise use any
>>>information contained herein. If you have received this e-mail in
>>>error, please notify the sender immediately
>>by
>>>replying to this message and delete this e-mail and associated attachments.
>>>Our company does not guarantee this e-mail is secure or free from viruses.
>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로
>>>발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을
>알려 드립니다. 잘못
>>수신하신
>>>경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기
>>>바랍니다. 협조에 감사 드립니다.
>
>
>This e-mail and any attachments herein may contain confidential or
>privileged information and is for the exclusive use of the intended
>recipient(s) named above. If you are not the intended recipient(s), you
>should not disseminate, distribute, retain, copy or otherwise use any
>information contained herein. If you have received this e-mail in
>error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments.
>Our company does not guarantee this e-mail is secure or free from viruses.
>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한
>수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.


This e-mail and any attachments herein may contain confidential or privileged information and is for the exclusive use of the intended recipient(s) named above. If you are not the intended recipient(s), you should not disseminate, distribute, retain, copy or otherwise use any information contained herein. If you have received this e-mail in error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments. Our company does not guarantee this e-mail is secure or free from viruses.
이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[Chen, Hongzhan]

>-----Original Message-----
>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Sent: Wednesday, January 25, 2023 12:54 PM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim)
>수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>; 이형석(Hyungseok
>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song) 책임연구원 두산로보틱스
><changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원
>두산로보틱스 <kyungchan.son@doosan.com>; 김동주(Dongjoo Kim)
>책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>I'm really thanks for your support.
>
>
>We set the Watchdog timeout value for 4.
>
>Could you explain the unit of value ?
>Is the value 4ms or 4s ?
>
>
>[*]   Watchdog support
>(4)     Watchdog timeout

If you type 'h' on the focused "Watchdog timeout" during make menuconfig, it would pop up the description like following. It clearly say that is in seconds.

x CONFIG_XENO_OPT_WATCHDOG_TIMEOUT:                                                                                                                    x
  x                                                                                                                                                      x
  x Watchdog timeout value (in seconds).                                                                                                                 x
  x                                                                                                                                                      x
  x Symbol: XENO_OPT_WATCHDOG_TIMEOUT [=4]
  x Type  : integer                                                                                                                                      x
  x Range : [1 60]                                                                                                                                       x
  x Defined at kernel/xenomai/Kconfig:481                                                                                                                x
  x   Prompt: Watchdog timeout                                                                                                                           x
  x   Depends on: XENOMAI [=y] && XENO_OPT_DEBUG [=y] && XENO_OPT_WATCHDOG [=y]                                                                          x
  x   Location:                                                                                                                                          x
  x     -> Xenomai/cobalt (XENOMAI [=y])                                                                                                                 x
  x       -> Debug support (XENO_OPT_DEBUG [=y])                                                                                                         x
  x         -> Watchdog support (XENO_OPT_WATCHDOG [=y])        

Regards

Hongzhan Chen

>
>
>Thanks
>
>-----Original Message-----
>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Sent: Tuesday, January 17, 2023 2:46 PM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim)
>수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>; 이형석(Hyungseok
>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song) 책임연구원 두산로보틱스
><changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원
>두산로보틱스 <kyungchan.son@doosan.com>; 김동주(Dongjoo Kim)
>책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>I'm really thanks for your support.
>
>
>We set the Watchdog timeout value for 4.
>
>Could you explain the unit of value ?
>Is the value 4ms or 4s ?
>
>
>[*]   Watchdog support
>(4)     Watchdog timeout
>
>
>
>Thanks
>  -----Original Message-----
>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>Sent: Tuesday, January 17, 2023 11:03 AM
>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim)
>수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>; 이형석(Hyungseok
>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song) 책임연구원 두산로보틱스
><changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원
>두산로보틱스 <kyungchan.son@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>주의하시기 바랍니다.
>
>CAUTION: This email is sent by an external account. Please take extra caution
>when clicking the link or opening the attachment.
>
>>-----Original Message-----
>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>
>>Sent: Tuesday, January 17, 2023 7:52 AM
>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스
>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>두산로보틱스
>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song) 책임연구원
>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>선임연구원 두산로보틱스
>><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>두산로보틱스
>><dongjoo5.kim@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>Dear Xenomai.org, Chen, Hongzhan
>>
>>I'm dong joo.
>>
>>I'm really thanks for your support.
>>
>>
>>If we apply as like below functions, The error result is not same.
>>Could you explain the difference between rt_task_sleep()and
>
>I am not familiar with alchemy skin, but from the implementation of
>rt_task_sleep, we can see that it would also call clock_nanosleep when you set
>timeout value but the clockid may be one of CLOCK_REALTIME and
>CLOCK_MONOTONIC  which depends on your configuration, Please check
>rt_task_sleep(lib/alchemy/task.c) -
>>threadobj_sleep(lib/copperplate/threadobj.c )-> clock_nanosleep
>
>>clock_nanosleep() ?
>>
>>
>>And, If our code run a cpu,
>>Is there any possibility to act context switching by other process ?
>
>Of course.
>
>>
>>
>>Is the Xenomai Scheduler preemption or non- preemption ?
>
>Xenomai scheduler support preemption but depends on how you configure
>schedule policy for your threads in real case.
>
>
>>
>>
>>While ( 1 ) {
>>
>>rt_task_sleep(1000000 );
>>
>>our code start ;
>>our cod end ;
>>
>>}
>>
>>: The result is segfault by our code.
>>
>>
>>While ( 1 ) {
>>
>>struct timespec ts;
>>      ts.tv_sec = 0;
>>      ts.tv_nsec = 1000000; /* 1ms */
>>
>>clock_nanosleep(CLOCK_REALTIME, 0, &ts, NULL);
>>
>>our code start ;
>>our cod end ;
>>
>>}
>>
>>: The result is Xenomai watchdog as like below.
>>   by Xenomai/cobalt: watchdog triggered CPU time limit exceeded (core
>>dumped)
>
>Watchdog triggered because Xenomai domain dominate the cpu too much
>time.  Please check which Thread dominate cpu. In addition , you may check
>/proc/xenomai/sched/threads or /proc/xenomai/sched/stat to find out if
>there is multi RT threads running at that time. If there is multi threads running ,
>the cpu yielded by one of rt threads by clock_nanosleep may be occupied by
>other RT threads which still be dominating CPU.
>
>Regards
>
>Hongzhan Chen
>
>>
>>
>>Thanks.
>>-----Original Message-----
>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>Sent: Wednesday, January 11, 2023 12:14 AM
>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스
>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>두산로보틱스
>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song) 책임연구원
>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>선임연구원 두산로보틱스
>><kyungchan.son@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>주의하시기 바랍니다.
>>
>>CAUTION: This email is sent by an external account. Please take extra
>>caution when clicking the link or opening the attachment.
>>
>>>-----Original Message-----
>>>From: Chen, Hongzhan
>>>Sent: Friday, January 6, 2023 10:36 AM
>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>두산로보틱스
>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>두산로보틱스
>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>두산로보틱스
>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>송창우(Changwoo Song) 책임연구원
>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>>선임연구원 두산로보틱스
>>><kyungchan.son@doosan.com>
>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>><dongjoo5.kim@doosan.com>
>>>>Sent: Thursday, January 5, 2023 5:50 PM
>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>두산로보틱스
>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>두산로보틱스
>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>두산로보틱스
>>>><sangjoon.kim@doosan.com>;
>>>이형석(Hyungseok
>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>송창우(Changwoo Song)
>>>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>;
>>손경찬(Kyungchan Son) 선임연구원
>>>>두산로보틱스 <kyungchan.son@doosan.com>; 김동주(Dongjoo Kim)
>>책임연구원 두산로보틱스
>>>><dongjoo5.kim@doosan.com>
>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>
>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>
>>>>I'm dong joo.
>>>>
>>>>I'm really thanks for your support.
>>>>
>>>>
>>>>If we test a rt_mutex_create, rt_mutex_acquire, rt_mutex_release with
>>>>Xenomai 2.6.5, The test result is same to Xenomai 3.
>>>>
>>>>Even though we disable rt_mutex_release API, the count increase
>>>>increase abnormally.
>>>>
>>>>Is the result normal case or not ?
>>>>
>>>>Could you share to us the comment about the result ?
>>>
>>>Following is the mutex description. When the mutex is owned by current
>>>task, it always can enter critical sections but just block any other
>>>task per my understanding.
>>>
>>>Mutex services.
>>>A mutex is a MUTual EXclusion object, and is useful for protecting
>>>shared data structures from concurrent modifications, and implementing
>>>critical sections and monitors.
>>>
>>>A mutex has two possible states: unlocked (not owned by any task), and
>>>locked (owned by one task). A mutex can never be owned by two
>>>different tasks simultaneously. A task attempting to lock a mutex that
>>>is already locked by another task is blocked until the latter unlocks the
>mutex first.
>>>
>>>Xenomai mutex services enforce a priority inheritance protocol in
>>>order to solve priority inversions.
>>
>>The implementation of rt_mutex_create set PTHREAD_MUTEX_RECURSIVE
>>attribution by default for the mutex, so the same thread can have multi
>>lock but avoid deadlock.
>>
>>Regards
>>
>>Hongzhan Chen
>>
>>>
>>>Regards
>>>
>>>Hongzhan Chen
>>>>
>>>>Thanks.
>>>>-----Original Message-----
>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>Sent: Thursday, January 5, 2023 6:41 PM
>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; 김동주(Dongjoo Kim)
>>책임연구원
>>>>두산로보틱스 <dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>두산로보틱스
>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>두산로보틱스
>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>두산로보틱스
>>>><sangjoon.kim@doosan.com>;
>>>이형석(Hyungseok
>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>송창우(Changwoo Song)
>>>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>;
>>손경찬(Kyungchan Son) 선임연구원
>>>>두산로보틱스 <kyungchan.son@doosan.com>
>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>
>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>>주의하시기 바랍니다.
>>>>
>>>>CAUTION: This email is sent by an external account. Please take extra
>>>>caution when clicking the link or opening the attachment.
>>>>
>>>>>-----Original Message-----
>>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>>Sent: Thursday, January 5, 2023 5:25 PM
>>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>;
>>>>>김세현(Sehyun Kim) 연구원
>>>>두산로보틱스
>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>두산로보틱스
>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>두산로보틱스
>>>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>>송창우(Changwoo Song) 책임연구원
>>>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>>>>선임연구원 두산로보틱스
>>>>><kyungchan.son@doosan.com>
>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>>>>>>Sent: Thursday, January 5, 2023 3:18 PM
>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>xenomai@xenomai.org
>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>;
>>>>>>김세현(Sehyun Kim) 연구원
>>>>>두산로보틱스
>>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>두산로보틱스
>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>두산로보틱스
>>>>>><sangjoon.kim@doosan.com>;
>>>>>이형석(Hyungseok
>>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>>송창우(Changwoo Song)
>>>>>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>;
>>>>손경찬(Kyungchan Son) 선임연구원
>>>>>>두산로보틱스 <kyungchan.son@doosan.com>; 김동주(Dongjoo Kim)
>>>>책임연구원 두산로보틱스
>>>>>><dongjoo5.kim@doosan.com>
>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>
>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>
>>>>>>I'm dong joo.
>>>>>>
>>>>>>Thanks for your support.
>>>>>>
>>>>>>I have one more questions.
>>>>>>
>>>>>>Is the posix-mutex realtime mutex or not ?
>>>>>
>>>>>Yes, it is realtime.
>>>>>
>>>>>>
>>>>>>And, Is there no problem to use the posix-mutex in the realtime Task ?
>>>>>
>>>>>No, I do not think there is problem to use posix-mutex in realttime
>>>>>task. You can see that posix mutex  test already be covered in each
>>>>>release as one of smokey test.
>>>>>
>>>>>>
>>>>>>
>>>>>>Finally, Is there any problem to use the rt_mutex_lock based on
>>>>>>Xenomai guide?
>>>>>
>>>>>From Xenomai 3 , all alchemy APIs such as rt_mutex_* actually is
>>>>>based on posix API, which is quite different from Xenomai 2.
>>>>
>>>>According to doc/asciidoc/MIGRATION.adoc,
>>>>
>>>>- Like +rt_mutex_inquire()+, +rt_cond_inquire()+ does not return the
>>>>count
>>>of
>>>>waiting tasks anymore.
>>>>
>>>>Regards
>>>>
>>>>Hongzhan Chen
>>>>>
>>>>>Regards
>>>>>
>>>>>Hongzhan Chen
>>>>>>
>>>>>>
>>>>>>Thanks.
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>>>Sent: Thursday, January 5, 2023 4:03 PM
>>>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>;
>>>>>>김세현(Sehyun Kim) 연구원
>>>>>두산로보틱스
>>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>두산로보틱스
>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>두산로보틱스
>>>>>><sangjoon.kim@doosan.com>;
>>>>>이형석(Hyungseok
>>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>>송창우(Changwoo Song)
>>>>>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>;
>>>>손경찬(Kyungchan Son) 선임연구원
>>>>>>두산로보틱스 <kyungchan.son@doosan.com>
>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>
>>>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람
>>시
>>>>주의하시기 바랍니다.
>>>>>>
>>>>>>CAUTION: This email is sent by an external account. Please take
>>>>>>extra caution when clicking the link or opening the attachment.
>>>>>>
>>>>>>Hi
>>>>>>
>>>>>>Why do not you use posix mutex like example in
>>>>>>testsuite/smokey/posix- mutex/posix-mutex.c?
>>>>>>
>>>>>>
>>>>>>Regards
>>>>>>
>>>>>>Hongzhan Chen
>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>
>>>>>>>Sent: Thursday, January 5, 2023 9:21 AM
>>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>>xenomai@xenomai.org
>>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>;
>>>>>>>김세현(Sehyun Kim) 연구원
>>>>>>두산로보틱스
>>>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>>두산로보틱스
>>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>>>두산로보틱스
>>>>>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>>>>송창우(Changwoo Song) 책임연구원
>>>>>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan
>Son)
>>>>>>선임연구원 두산로보틱스
>>>>>>><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>>>>>두산로보틱스
>>>>>>><dongjoo5.kim@doosan.com>
>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>
>>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>>
>>>>>>>I'm dong joo.
>>>>>>>
>>>>>>>Could you help me to solve this problem ?
>>>>>>>
>>>>>>>Thanks.
>>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>
>>>>>>>Sent: Monday, January 2, 2023 12:10 PM
>>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>>xenomai@xenomai.org
>>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>;
>>>>>>>김세현(Sehyun Kim) 연구원
>>>>>>두산로보틱스
>>>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>>두산로보틱스
>>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>>>두산로보틱스
>>>>>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>>>>송창우(Changwoo Song) 책임연구원
>>>>>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan
>Son)
>>>>>>선임연구원 두산로보틱스
>>>>>>><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>>>>>두산로보틱스
>>>>>>><dongjoo5.kim@doosan.com>
>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>
>>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>>
>>>>>>>I'm dong joo.
>>>>>>>
>>>>>>>We have tested the API of Xenomai rt_mutex as like
>>>>>>>rt_mutex_create, rt_mutex_acquire, rt_mutex_release.
>>>>>>>
>>>>>>>
>>>>>>>If we block the rt_mutex_release,
>>>>>>>The next sequence can't get a rt_mutex_acquire by the previous
>>>>>>>sequence don't call rt_mutex_release before.
>>>>>>>
>>>>>>>So, The result of count must be 0 what we think.
>>>>>>>
>>>>>>>But, The result of count increase abnormally as like below. Is
>>>>>>>there any problem about rt_mutex_acquire or rt_mutex_release ?
>>>>>>>
>>>>>>>
>>>>>>>If we test the API of Xenomai rt_sem as like rt_sem_create,
>>>>>>>rt_sem_p, rt_sem_v, The result of count is 0.
>>>>>>>
>>>>>>>
>>>>>>>rt_mutex_create 0
>>>>>>>task info
>>>>>>>rt_mutex_acquire 0
>>>>>>>Loop count: 0, Loop time: 355521102 ms rt_mutex_acquire 0 Loop
>count:
>>>>>>>1, Loop time: 355521103 ms rt_mutex_acquire 0 Loop count: 2, Loop
>>>>>>>time: 355521104 ms rt_mutex_acquire 0 Loop count: 3, Loop time:
>>>>>>>355521105 ms rt_mutex_acquire 0 Loop count: 4, Loop time:
>>>>>>>355521106 ms rt_mutex_acquire 0 Loop count: 5, Loop time:
>>>>>>>355521107 ms rt_mutex_acquire 0 Loop count: 6, Loop time:
>>>>>>>355521108 ms rt_mutex_acquire 0 Loop count: 7, Loop time:
>>>>>>>355521109 ms rt_mutex_acquire 0 Loop count: 8, Loop time:
>>>>>>>355521110 ms rt_mutex_acquire 0
>>>>>>>
>>>>>>>
>>>>>>>void loop_task_proc(void *arg) {
>>>>>>>
>>>>>>>        int cnt = 0;
>>>>>>>        int ret = 0 ;
>>>>>>>
>>>>>>>        RTIME tstart1;
>>>>>>>
>>>>>>>        RT_MUTEX            m_tMutex;
>>>>>>>//      RT_SEM              m_tSemaphore;
>>>>>>>        ret = rt_mutex_create(&m_tMutex, "test");
>>>>>>>        rt_printf("rt_mutex_create %d\n", ret ) ;
>>>>>>>
>>>>>>>//      ret = rt_sem_create(&m_tSemaphore, "test", 1, S_FIFO);
>>>>>>>//      rt_printf("rt_sem_create %d\n", ret ) ;
>>>>>>>
>>>>>>>        //Print the info
>>>>>>>        rt_printf("task info \n");
>>>>>>>
>>>>>>>        rt_task_set_periodic(NULL, TM_NOW, LOOP_PERIOD);
>>>>>>>
>>>>>>>
>>>>>>>        //Start the task loop
>>>>>>>        while (1) {
>>>>>>>        ret =   rt_mutex_acquire(&m_tMutex, TM_INFINITE );
>>>>>>>        rt_printf("rt_mutex_acquire %d\n", ret ) ;
>>>>>>>
>>>>>>>//      rt_sem_p(&m_tSemaphore, TM_INFINITE ) ;
>>>>>>>//      rt_printf("rt_sem_p %d\n", ret ) ;
>>>>>>>//
>>>>>>>        tstart1 = rt_timer_read () ;
>>>>>>>        rt_printf("Loop count: %d, Loop time: %llu ms\n", cnt,
>>>>>>>tstart1 /
>>>>>>1000000 );
>>>>>>>        cnt++;
>>>>>>>        rt_task_wait_period(NULL);
>>>>>>>
>>>>>>>//      ret =           rt_mutex_release(&m_tMutex);
>>>>>>>//      rt_printf("rt_mutex_release %d\n", ret ) ;
>>>>>>>//      rt_sem_v(&m_tSemaphore);
>>>>>>>//      rt_printf("rt_sem_v %d\n", ret ) ;
>>>>>>>        }
>>>>>>>}
>>>>>>>
>>>>>>>int main(int argc, char* argv[])
>>>>>>>{
>>>>>>>
>>>>>>>        RT_TASK loop_task;
>>>>>>>        rt_task_create(&loop_task, "basicmath_small", 0, 50, 0);
>>>>>>>        rt_task_start(&loop_task, &loop_task_proc, 0);
>>>>>>>        //Wait for Ctrl-C
>>>>>>>        pause();
>>>>>>>        return 0;
>>>>>>>
>>>>>>>
>>>>>>>}
>>>>>>>
>>>>>>>Thanks.
>>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>>>>Sent: Wednesday, October 26, 2022 11:43 AM
>>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>>xenomai@xenomai.org
>>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>;
>>>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>>>두산로보틱스
>>>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>>>두산로보틱스
>>>>>>><sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>>>>>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>>두산로보틱스
>>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>>>두산로보틱스
>>>>>>><sangjoon.kim@doosan.com>; 김동주(Dongjoo
>>>>>>>Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>
>>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>>
>>>>>>>I'm dong joo.
>>>>>>>
>>>>>>>I have a basic question.
>>>>>>>
>>>>>>>If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI
>>>Processor
>>>>>>>CONFIG, We can't check the current cpu freq by sysnode.
>>>>>>>
>>>>>>>Because, sysnode of cpu freq is related to CPU_FREQ CONFIG and
>>>>>>>ACPI Processor CONFIG as i know.
>>>>>>>
>>>>>>>
>>>>>>>If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI
>>>Processor
>>>>>>>CONFIG, Could you expect the current cpu freq in the intel hw system ?
>>>>>>>
>>>>>>>Actually, The minimum cpu clock of our hw system is very low.
>>>>>>>
>>>>>>>If our hw system operate with minimum cpu clock always, I worry
>>>>>>>about the performance of hw system.
>>>>>>>
>>>>>>>
>>>>>>>sys/devices/system/cpu/cpu0/cpufreq# ls affected_cpus
>>>>>>>cpuinfo_cur_freq  cpuinfo_min_freq
>>>>freqdomain_cpus
>>>>>>>scaling_available_frequencies  scaling_cur_freq  scaling_governor
>>>>>>>scaling_min_freq  stats
>>>>>>>bios_limit     cpuinfo_max_freq  cpuinfo_transition_latency
>>related_cpus
>>>>>>>scaling_available_governors    scaling_driver    scaling_max_freq
>>>>>>>scaling_setspeed
>>>>>>>
>>>>>>>
>>>>>>>Thanks.
>>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>>>>Sent: Tuesday, October 25, 2022 5:24 PM
>>>>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>;
>>>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>>>두산로보틱스
>>>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>>>두산로보틱스
>>>>>>><sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>>>>>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>>두산로보틱스
>>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>>>두산로보틱스
>>>>>>><sangjoon.kim@doosan.com>
>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>
>>>>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일
>열람
>>>시
>>>>>>주의하시기 바랍니다.
>>>>>>>
>>>>>>>CAUTION: This email is sent by an external account. Please take
>>>>>>>extra caution when clicking the link or opening the attachment.
>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>
>>>>>>>>Sent: Tuesday, October 25, 2022 3:29 PM
>>>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>>>xenomai@xenomai.org
>>>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>>><youngchul3.park@doosan.com>;
>>>>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>>>>두산로보틱스
>>>>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>>>>두산로보틱스
>>>>>>>><sehyun2.kim@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>>>>>>두산로보틱스
>>>>>>>><dongjoo5.kim@doosan.com>; 이재석(Jaesuk Lee) 상무
>>두산로보틱스
>>>>>>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>>>두산로보틱스
>>>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon
>>>>>>>>Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>
>>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>>
>>>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>>>
>>>>>>>>I'm dong joo.
>>>>>>>>
>>>>>>>>After we do a aging test as like latency, We get a system hang
>>>>>>>>about ten hours later.
>>>>>>>>
>>>>>>>>At that time, Our system don't detect usb mouse.
>>>>>>>>
>>>>>>>>After rebooting our system by force, there is no significative
>>>>>>>>log in the kernel log or syslog.
>>>>>>>>
>>>>>>>>Could you help to us how to solve this issue ?
>>>>>>>
>>>>>>>Just as mentioned as in https://secure-
>>>>>>>web.cisco.com/1ll9UQp4RYnYXuVMxAlJKaDxV1RdMZtBcG3e_jDi4TlIxD
>>M
>>>Tz
>>>>F
>>>>>>M
>>>>>>>tJguJhndpS2BnNhGoAWwBP-G2UCWlarucvId1iz_ea_AU-
>>>>>>>U__8Gq6ZgF285KW8SRPHKr7NeWgE4dKG8o8PGMNJ3-
>>>>>>>lAB4xdptdPAk1vfJe8AL_Tt6oCEoT0OAr4RrSIjzqtmugt8EHD-
>>>>>>>jvxghKHjaWu1eGDkzOYtKpcV8WhZnz1wLItIZdChYT1xlXsFTU7-
>>>>>>>GnJhN2jLvMMlZgkMxzQLejJ2aB1wogBTkBIipva21mNGaSFb_sSZhX9ycwi
>T
>>7
>>>>U
>>>>>M
>>>>>>>UfQg5lyHCPZPEeP6/https%3A%2F%2Fxenomai.org%2Fpipermail%2Fxe
>n
>>o
>>>>m
>>>>>ai%
>>>>>>>2F2022-April%2F047495.html
>>>>>>>1. It is highly recommended to use a UART as kernel debug output.
>>>>>>>2. enable CONFIG_XENO_OPT_WATCHDOG for xenomai, system will be
>>>>able
>>>>>>to
>>>>>>>tell RT application "hangs" (infinite loop at high prio) apart
>>>>>>>from real hangs/crashes.
>>>>>>>
>>>>>>>Regards
>>>>>>>
>>>>>>>Hongzhan Chen
>>>>>>>>
>>>>>>>>
>>>>>>>>We set up our system as like below sw.
>>>>>>>>
>>>>>>>>1. Xubuntu 18.04 LTS 32bit
>>>>>>>>
>>>>>>>>2. Linux kernel 4.1.18 32bit
>>>>>>>>
>>>>>>>>3. Xenomai 3.0.8 32bit
>>>>>>>>
>>>>>>>>4. Kernel config
>>>>>>>>   We refer to the xenomai page as like below.
>>>>>>>>
>>>>>>>>https://secure-
>>>>>>>web.cisco.com/1nAW3bSL64gGRUPlQWKtShagcypkiReyVX7nhG1T-J
>>>>>>>>upEWaqU-3hnCSt542V_mEwX-
>>>>>>>_8HsjCaWtSuQnJ3056Yq52DypR5psiqKgrOSq6pbk6xe-tw
>>>>>>>>xYZhwwm0akkU4iVwFscbrRTWdk2Ul-
>>>>>>>9fU2HilSTJ8rzI8X9LIfFg2foor5t9LawggXyjgq3
>>>>>>>>QqwJktjRWEhqL8gFDP2PpsmxrTgVK6NzJdcBxzyOGo_jmjjiO009l74YL2
>U
>>5
>>>K
>>>>e
>>>>>3
>>>>>>A
>>>>>>>7kc1AX7
>>>>>>>>IV_t016CRGEK4QyAKRuSTqKzFm8t4flDV7eBT4m43w-o_SoFrKq-
>>>>>>>AA7ZIKEYPEgpqq/http
>>>>>>>>s%3A%2F%2Fsource.denx.de%2FXenomai%2Fxenomai%2F-
>>>>>>>>/wikis/Configuring_For_X86_Based_Dual_Kernels#user-content-x86-
>>>>>>>>processor-type
>>>>>>>>
>>>>>>>>Thanks.
>>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>>>>>Sent: Friday, August 26, 2022 2:40 PM
>>>>>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>;
>>>>>>>>xenomai@xenomai.org
>>>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>>><youngchul3.park@doosan.com>;
>>>>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>>>>두산로보틱스
>>>>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>>>>두산로보틱스
>>>>>>>><sehyun2.kim@doosan.com>
>>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>>
>>>>>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일
>>열람
>>>>시
>>>>>>>주의하시기 바랍니다.
>>>>>>>>
>>>>>>>>CAUTION: This email is sent by an external account. Please take
>>>>>>>>extra caution when clicking the link or opening the attachment.
>>>>>>>>
>>>>>>>>>-----Original Message-----
>>>>>>>>>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>>>>>>>>>Sent: Friday, August 26, 2022 10:41 AM
>>>>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>>>>xenomai@xenomai.org
>>>>>>>>>Cc: ???(Youngchul Park) ????? ??????
>>>>>>>><youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ??????
>>>>>>>><kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ??????
>>>>>>>><sehyun2.kim@doosan.com>; ???(Dongjoo Kim) ????? ??????
>>>>>>>><dongjoo5.kim@doosan.com>
>>>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>>>
>>>>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>>>>
>>>>>>>>>I'm dong joo.
>>>>>>>>>
>>>>>>>>>Thank you for your reply to us our questions.
>>>>>>>>>
>>>>>>>>>And, We have checked the value of TICK_NSEC int our system.
>>>>>>>>>
>>>>>>>>>#define TICK_NSEC ((NSEC_PER_SEC+HZ/2)/HZ)
>>>>>>>>>#define NSEC_PER_SEC   1000000000L
>>>>>>>>>HZ  250 ( Max 1000 )
>>>>>>>>>
>>>>>>>>>The value of TICK_NSEC is defined by linux kernel.
>>>>>>>>>And, Both NSEC_PER_SEC and HZ calculate the value of TICK_NSEC.
>>>>>>>>>
>>>>>>>>>So, The current value of TICK_NSEC is 4ms based on 250 HZ.
>>>>>>>>>And, If we change the value of HZ to 1000, The value of
>>>>>>>>>TICK_NSEC may be
>>>>>>>>1ms.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>We hope to process a task every 20us using rt_task_yield as like
>>>>>>>>>Xenomai
>>>>>>>>2.6.5.
>>>>>>>>>
>>>>>>>>>Is there any method to achieve 20us task delay using
>>>>>>>>>rt_task_yield or another
>>>>>>>>xenomai method ?
>>>>>>>>>And, Is there any problem to reduce the delay more less than
>>>>TICK_NSEC ?
>>>>>>>>
>>>>>>>>I just went through the implementation of rt_task_yield of Xeomai
>>>>>>>>2.6.5 and found that it is totally different from Xenomai 3.0.8.
>>>>>>>>If you want to yield about 20us for current RT thread ,you may
>>>>>>>>try call clock_nanosleep .
>>>>>>>>.
>>>>>>>>Regards
>>>>>>>>
>>>>>>>>Hongzhan Chen
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>Really Thanks.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>This e-mail and any attachments herein may contain confidential
>>>>>>>>or privileged information and is for the exclusive use of the
>>>>>>>>intended
>>>>>>>>recipient(s) named above. If you are not the intended
>>>>>>>>recipient(s), you should not disseminate, distribute, retain,
>>>>>>>>copy or otherwise use any information contained herein. If you
>>>>>>>>have received this e-mail in error, please notify the sender
>>>>>>>>immediately by replying to this message and
>>>>>>>delete this e-mail and associated attachments.
>>>>>>>>Our company does not guarantee this e-mail is secure or free from
>>>>viruses.
>>>>>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>>>>>포함하고
>>>>>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>>>>>>용도로도 이를
>>>>>>>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>>>>>>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>>>>>>>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>>>>>>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>>>>>>>
>>>>>>>
>>>>>>>This e-mail and any attachments herein may contain confidential or
>>>>>>>privileged information and is for the exclusive use of the
>>>>>>>intended
>>>>>>>recipient(s) named above. If you are not the intended
>>>>>>>recipient(s), you should not disseminate, distribute, retain, copy
>>>>>>>or otherwise use any information contained herein. If you have
>>>>>>>received this e-mail in error, please notify the sender
>>>>>>>immediately by replying to this message and
>>>>>>delete this e-mail and associated attachments.
>>>>>>>Our company does not guarantee this e-mail is secure or free from
>>>viruses.
>>>>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>>>>포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>>>>용도로도 이를
>>>>>>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>>>>>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>>>>>>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>>>>>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>>>>>>
>>>>>>
>>>>>>This e-mail and any attachments herein may contain confidential or
>>>>>privileged
>>>>>>information and is for the exclusive use of the intended
>>>>>>recipient(s) named above. If you are not the intended recipient(s),
>>>>>>you should not disseminate, distribute, retain, copy or otherwise
>>>>>>use any information contained herein. If you have received this
>>>>>>e-mail in error, please notify the sender immediately
>>>>>by
>>>>>>replying to this message and delete this e-mail and associated
>>attachments.
>>>>>>Our company does not guarantee this e-mail is secure or free from
>>viruses.
>>>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>>>포함하고
>>>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>>>>용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로
>>>>>>발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을
>>>>알려 드립니다. 잘못
>>>>>수신하신
>>>>>>경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기
>>>>>>바랍니다. 협조에 감사 드립니다.
>>>>
>>>>
>>>>This e-mail and any attachments herein may contain confidential or
>>>privileged
>>>>information and is for the exclusive use of the intended recipient(s)
>>>>named above. If you are not the intended recipient(s), you should not
>>>>disseminate, distribute, retain, copy or otherwise use any
>>>>information contained herein. If you have received this e-mail in
>>>>error, please notify the sender immediately
>>>by
>>>>replying to this message and delete this e-mail and associated attachments.
>>>>Our company does not guarantee this e-mail is secure or free from viruses.
>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>포함하고
>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>>용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로
>>>>발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을
>>알려 드립니다. 잘못
>>>수신하신
>>>>경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기
>>>>바랍니다. 협조에 감사 드립니다.
>>
>>
>>This e-mail and any attachments herein may contain confidential or
>>privileged information and is for the exclusive use of the intended
>>recipient(s) named above. If you are not the intended recipient(s), you
>>should not disseminate, distribute, retain, copy or otherwise use any
>>information contained herein. If you have received this e-mail in
>>error, please notify the sender immediately by replying to this message and
>delete this e-mail and associated attachments.
>>Our company does not guarantee this e-mail is secure or free from viruses.
>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한
>>수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를
>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>
>
>This e-mail and any attachments herein may contain confidential or privileged
>information and is for the exclusive use of the intended recipient(s) named
>above. If you are not the intended recipient(s), you should not disseminate,
>distribute, retain, copy or otherwise use any information contained herein. If
>you have received this e-mail in error, please notify the sender immediately by
>replying to this message and delete this e-mail and associated attachments.
>Our company does not guarantee this e-mail is secure or free from viruses.
>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한
>수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를
>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에
>관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신
>경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기
>바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[김동주(Dongjoo Kim) 책임연구원 두산로보틱스]

Dear Xenomai.org, Chen, Hongzhan

I'm dong joo.

I'm really thanks for your support.

We have a critical issue, but I can't find any solution.


If we run  our system for long run test,
Xenomai watchdog signal to our BTask after 8~10 hours as like below.


[Xenomai] watchdog triggered on CPU #2 -- runaway thread ' Btask ' signale



Our BTask just call A function every 1ms.
So, I have checked the time between before A function and after A function using rt_printf.

I have checked all the rt_printf log. But, There is abnormal status.

The processing time of A function is about 2us even though Xenomai watchdog signal to our BTask.


How do we solve this problem?
Could you help to us to debug this issue ?


RT_TASK Btask;
unsigned long long time2 = 0 ;
unsinged long long time3 = 0 ;


BThread ( void ( *pArg )
{

while (1)
{
        rt_task_sleep ( 1000000 );

        time2= (rt_timer_read() / 1000 );
        rt_printf(" time2 %llu\n",time2 ) ;
        A func ();
        time3= (rt_timer_read() / 1000 );
        rt_printf(" time3 %llu\n",time3 ) ;
}

int main ( int argc, char * argv [] )
{
        cpu_set_t cpus ;
        rt_task_create ( &BTask, "Btask", 8 * 1024 * 1024, PRIORITY_LOWLOW, T_JOINABLE);
        CPU_ZERO(&cpus);
        CPU_SET(2, &cpus);
        rt_task_set_affinity(&BTask, &cpus);

        rt_task_start(&BTask, &BThread, NULL);
}


Thanks.
-----Original Message-----
From: Chen, Hongzhan <hongzhan.chen@intel.com>
Sent: Monday, January 30, 2023 9:56 AM
To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>; xenomai@xenomai.org
Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스 <sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>; 이형석(Hyungseok Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>; 송창우(Changwoo Song) 책임연구원 두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원 두산로보틱스 <kyungchan.son@doosan.com>
Subject: RE: What causes the latency of the rt_task_yield() API?

주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시 주의하시기 바랍니다.

CAUTION: This email is sent by an external account. Please take extra caution when clicking the link or opening the attachment.

>-----Original Message-----
>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Sent: Wednesday, January 25, 2023 12:54 PM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스
><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스
><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>; 송창우(Changwoo Song) 책임연구원
>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원 두산로보틱스
><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>I'm really thanks for your support.
>
>
>We set the Watchdog timeout value for 4.
>
>Could you explain the unit of value ?
>Is the value 4ms or 4s ?
>
>
>[*]   Watchdog support
>(4)     Watchdog timeout

If you type 'h' on the focused "Watchdog timeout" during make menuconfig, it would pop up the description like following. It clearly say that is in seconds.

x CONFIG_XENO_OPT_WATCHDOG_TIMEOUT:                                                                                                                    x
  x                                                                                                                                                      x
  x Watchdog timeout value (in seconds).                                                                                                                 x
  x                                                                                                                                                      x
  x Symbol: XENO_OPT_WATCHDOG_TIMEOUT [=4]
  x Type  : integer                                                                                                                                      x
  x Range : [1 60]                                                                                                                                       x
  x Defined at kernel/xenomai/Kconfig:481                                                                                                                x
  x   Prompt: Watchdog timeout                                                                                                                           x
  x   Depends on: XENOMAI [=y] && XENO_OPT_DEBUG [=y] && XENO_OPT_WATCHDOG [=y]                                                                          x
  x   Location:                                                                                                                                          x
  x     -> Xenomai/cobalt (XENOMAI [=y])                                                                                                                 x
  x       -> Debug support (XENO_OPT_DEBUG [=y])                                                                                                         x
  x         -> Watchdog support (XENO_OPT_WATCHDOG [=y])

Regards

Hongzhan Chen

>
>
>Thanks
>
>-----Original Message-----
>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Sent: Tuesday, January 17, 2023 2:46 PM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스
><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스
><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>; 송창우(Changwoo Song) 책임연구원
>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원 두산로보틱스
><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>I'm really thanks for your support.
>
>
>We set the Watchdog timeout value for 4.
>
>Could you explain the unit of value ?
>Is the value 4ms or 4s ?
>
>
>[*]   Watchdog support
>(4)     Watchdog timeout
>
>
>
>Thanks
>  -----Original Message-----
>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>Sent: Tuesday, January 17, 2023 11:03 AM
>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원 두산로보틱스
><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원 두산로보틱스
><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>; 송창우(Changwoo Song) 책임연구원
>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원 두산로보틱스
><kyungchan.son@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시 주의하시기 바랍니다.
>
>CAUTION: This email is sent by an external account. Please take extra
>caution when clicking the link or opening the attachment.
>
>>-----Original Message-----
>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>
>>Sent: Tuesday, January 17, 2023 7:52 AM
>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스
>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>두산로보틱스
>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song) 책임연구원
>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>선임연구원 두산로보틱스
>><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>두산로보틱스
>><dongjoo5.kim@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>Dear Xenomai.org, Chen, Hongzhan
>>
>>I'm dong joo.
>>
>>I'm really thanks for your support.
>>
>>
>>If we apply as like below functions, The error result is not same.
>>Could you explain the difference between rt_task_sleep()and
>
>I am not familiar with alchemy skin, but from the implementation of
>rt_task_sleep, we can see that it would also call clock_nanosleep when
>you set timeout value but the clockid may be one of CLOCK_REALTIME and
>CLOCK_MONOTONIC  which depends on your configuration, Please check
>rt_task_sleep(lib/alchemy/task.c) -
>>threadobj_sleep(lib/copperplate/threadobj.c )-> clock_nanosleep
>
>>clock_nanosleep() ?
>>
>>
>>And, If our code run a cpu,
>>Is there any possibility to act context switching by other process ?
>
>Of course.
>
>>
>>
>>Is the Xenomai Scheduler preemption or non- preemption ?
>
>Xenomai scheduler support preemption but depends on how you configure
>schedule policy for your threads in real case.
>
>
>>
>>
>>While ( 1 ) {
>>
>>rt_task_sleep(1000000 );
>>
>>our code start ;
>>our cod end ;
>>
>>}
>>
>>: The result is segfault by our code.
>>
>>
>>While ( 1 ) {
>>
>>struct timespec ts;
>>      ts.tv_sec = 0;
>>      ts.tv_nsec = 1000000; /* 1ms */
>>
>>clock_nanosleep(CLOCK_REALTIME, 0, &ts, NULL);
>>
>>our code start ;
>>our cod end ;
>>
>>}
>>
>>: The result is Xenomai watchdog as like below.
>>   by Xenomai/cobalt: watchdog triggered CPU time limit exceeded (core
>>dumped)
>
>Watchdog triggered because Xenomai domain dominate the cpu too much
>time.  Please check which Thread dominate cpu. In addition , you may
>check /proc/xenomai/sched/threads or /proc/xenomai/sched/stat to find
>out if there is multi RT threads running at that time. If there is
>multi threads running , the cpu yielded by one of rt threads by
>clock_nanosleep may be occupied by other RT threads which still be dominating CPU.
>
>Regards
>
>Hongzhan Chen
>
>>
>>
>>Thanks.
>>-----Original Message-----
>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>Sent: Wednesday, January 11, 2023 12:14 AM
>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스
>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>두산로보틱스
>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song) 책임연구원
>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>선임연구원 두산로보틱스
>><kyungchan.son@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>주의하시기 바랍니다.
>>
>>CAUTION: This email is sent by an external account. Please take extra
>>caution when clicking the link or opening the attachment.
>>
>>>-----Original Message-----
>>>From: Chen, Hongzhan
>>>Sent: Friday, January 6, 2023 10:36 AM
>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>두산로보틱스
>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>두산로보틱스
>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>두산로보틱스
>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>송창우(Changwoo Song) 책임연구원
>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>>선임연구원 두산로보틱스
>>><kyungchan.son@doosan.com>
>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>><dongjoo5.kim@doosan.com>
>>>>Sent: Thursday, January 5, 2023 5:50 PM
>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>;
>>>>김세현(Sehyun Kim) 연구원
>>>두산로보틱스
>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>두산로보틱스
>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>두산로보틱스
>>>><sangjoon.kim@doosan.com>;
>>>이형석(Hyungseok
>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>송창우(Changwoo Song)
>>>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>;
>>손경찬(Kyungchan Son) 선임연구원
>>>>두산로보틱스 <kyungchan.son@doosan.com>; 김동주(Dongjoo Kim)
>>책임연구원 두산로보틱스
>>>><dongjoo5.kim@doosan.com>
>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>
>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>
>>>>I'm dong joo.
>>>>
>>>>I'm really thanks for your support.
>>>>
>>>>
>>>>If we test a rt_mutex_create, rt_mutex_acquire, rt_mutex_release
>>>>with Xenomai 2.6.5, The test result is same to Xenomai 3.
>>>>
>>>>Even though we disable rt_mutex_release API, the count increase
>>>>increase abnormally.
>>>>
>>>>Is the result normal case or not ?
>>>>
>>>>Could you share to us the comment about the result ?
>>>
>>>Following is the mutex description. When the mutex is owned by
>>>current task, it always can enter critical sections but just block
>>>any other task per my understanding.
>>>
>>>Mutex services.
>>>A mutex is a MUTual EXclusion object, and is useful for protecting
>>>shared data structures from concurrent modifications, and
>>>implementing critical sections and monitors.
>>>
>>>A mutex has two possible states: unlocked (not owned by any task),
>>>and locked (owned by one task). A mutex can never be owned by two
>>>different tasks simultaneously. A task attempting to lock a mutex
>>>that is already locked by another task is blocked until the latter
>>>unlocks the
>mutex first.
>>>
>>>Xenomai mutex services enforce a priority inheritance protocol in
>>>order to solve priority inversions.
>>
>>The implementation of rt_mutex_create set PTHREAD_MUTEX_RECURSIVE
>>attribution by default for the mutex, so the same thread can have
>>multi lock but avoid deadlock.
>>
>>Regards
>>
>>Hongzhan Chen
>>
>>>
>>>Regards
>>>
>>>Hongzhan Chen
>>>>
>>>>Thanks.
>>>>-----Original Message-----
>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>Sent: Thursday, January 5, 2023 6:41 PM
>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; 김동주(Dongjoo Kim)
>>책임연구원
>>>>두산로보틱스 <dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스 <youngchul3.park@doosan.com>;
>>>>김세현(Sehyun Kim) 연구원
>>>두산로보틱스
>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>두산로보틱스
>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>두산로보틱스
>>>><sangjoon.kim@doosan.com>;
>>>이형석(Hyungseok
>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>송창우(Changwoo Song)
>>>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>;
>>손경찬(Kyungchan Son) 선임연구원
>>>>두산로보틱스 <kyungchan.son@doosan.com>
>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>
>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>>주의하시기 바랍니다.
>>>>
>>>>CAUTION: This email is sent by an external account. Please take
>>>>extra caution when clicking the link or opening the attachment.
>>>>
>>>>>-----Original Message-----
>>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>>Sent: Thursday, January 5, 2023 5:25 PM
>>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>;
>>>>>김세현(Sehyun Kim) 연구원
>>>>두산로보틱스
>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>두산로보틱스
>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>두산로보틱스
>>>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>>송창우(Changwoo Song) 책임연구원
>>>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>>>>선임연구원 두산로보틱스
>>>>><kyungchan.son@doosan.com>
>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>>>>>>Sent: Thursday, January 5, 2023 3:18 PM
>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>xenomai@xenomai.org
>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>;
>>>>>>김세현(Sehyun Kim) 연구원
>>>>>두산로보틱스
>>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>두산로보틱스
>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>두산로보틱스
>>>>>><sangjoon.kim@doosan.com>;
>>>>>이형석(Hyungseok
>>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>>송창우(Changwoo Song)
>>>>>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>;
>>>>손경찬(Kyungchan Son) 선임연구원
>>>>>>두산로보틱스 <kyungchan.son@doosan.com>; 김동주(Dongjoo Kim)
>>>>책임연구원 두산로보틱스
>>>>>><dongjoo5.kim@doosan.com>
>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>
>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>
>>>>>>I'm dong joo.
>>>>>>
>>>>>>Thanks for your support.
>>>>>>
>>>>>>I have one more questions.
>>>>>>
>>>>>>Is the posix-mutex realtime mutex or not ?
>>>>>
>>>>>Yes, it is realtime.
>>>>>
>>>>>>
>>>>>>And, Is there no problem to use the posix-mutex in the realtime Task ?
>>>>>
>>>>>No, I do not think there is problem to use posix-mutex in realttime
>>>>>task. You can see that posix mutex  test already be covered in each
>>>>>release as one of smokey test.
>>>>>
>>>>>>
>>>>>>
>>>>>>Finally, Is there any problem to use the rt_mutex_lock based on
>>>>>>Xenomai guide?
>>>>>
>>>>>From Xenomai 3 , all alchemy APIs such as rt_mutex_* actually is
>>>>>based on posix API, which is quite different from Xenomai 2.
>>>>
>>>>According to doc/asciidoc/MIGRATION.adoc,
>>>>
>>>>- Like +rt_mutex_inquire()+, +rt_cond_inquire()+ does not return the
>>>>count
>>>of
>>>>waiting tasks anymore.
>>>>
>>>>Regards
>>>>
>>>>Hongzhan Chen
>>>>>
>>>>>Regards
>>>>>
>>>>>Hongzhan Chen
>>>>>>
>>>>>>
>>>>>>Thanks.
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>>>Sent: Thursday, January 5, 2023 4:03 PM
>>>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>;
>>>>>>김세현(Sehyun Kim) 연구원
>>>>>두산로보틱스
>>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>두산로보틱스
>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>두산로보틱스
>>>>>><sangjoon.kim@doosan.com>;
>>>>>이형석(Hyungseok
>>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>>송창우(Changwoo Song)
>>>>>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>;
>>>>손경찬(Kyungchan Son) 선임연구원
>>>>>>두산로보틱스 <kyungchan.son@doosan.com>
>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>
>>>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람
>>시
>>>>주의하시기 바랍니다.
>>>>>>
>>>>>>CAUTION: This email is sent by an external account. Please take
>>>>>>extra caution when clicking the link or opening the attachment.
>>>>>>
>>>>>>Hi
>>>>>>
>>>>>>Why do not you use posix mutex like example in
>>>>>>testsuite/smokey/posix- mutex/posix-mutex.c?
>>>>>>
>>>>>>
>>>>>>Regards
>>>>>>
>>>>>>Hongzhan Chen
>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>
>>>>>>>Sent: Thursday, January 5, 2023 9:21 AM
>>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>>xenomai@xenomai.org
>>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>;
>>>>>>>김세현(Sehyun Kim) 연구원
>>>>>>두산로보틱스
>>>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>>두산로보틱스
>>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>>>두산로보틱스
>>>>>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>>>>송창우(Changwoo Song) 책임연구원
>>>>>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan
>Son)
>>>>>>선임연구원 두산로보틱스
>>>>>>><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>>>>>두산로보틱스
>>>>>>><dongjoo5.kim@doosan.com>
>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>
>>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>>
>>>>>>>I'm dong joo.
>>>>>>>
>>>>>>>Could you help me to solve this problem ?
>>>>>>>
>>>>>>>Thanks.
>>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>
>>>>>>>Sent: Monday, January 2, 2023 12:10 PM
>>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>>xenomai@xenomai.org
>>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>;
>>>>>>>김세현(Sehyun Kim) 연구원
>>>>>>두산로보틱스
>>>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>>두산로보틱스
>>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>>>두산로보틱스
>>>>>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>>>>송창우(Changwoo Song) 책임연구원
>>>>>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan
>Son)
>>>>>>선임연구원 두산로보틱스
>>>>>>><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>>>>>두산로보틱스
>>>>>>><dongjoo5.kim@doosan.com>
>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>
>>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>>
>>>>>>>I'm dong joo.
>>>>>>>
>>>>>>>We have tested the API of Xenomai rt_mutex as like
>>>>>>>rt_mutex_create, rt_mutex_acquire, rt_mutex_release.
>>>>>>>
>>>>>>>
>>>>>>>If we block the rt_mutex_release, The next sequence can't get a
>>>>>>>rt_mutex_acquire by the previous sequence don't call
>>>>>>>rt_mutex_release before.
>>>>>>>
>>>>>>>So, The result of count must be 0 what we think.
>>>>>>>
>>>>>>>But, The result of count increase abnormally as like below. Is
>>>>>>>there any problem about rt_mutex_acquire or rt_mutex_release ?
>>>>>>>
>>>>>>>
>>>>>>>If we test the API of Xenomai rt_sem as like rt_sem_create,
>>>>>>>rt_sem_p, rt_sem_v, The result of count is 0.
>>>>>>>
>>>>>>>
>>>>>>>rt_mutex_create 0
>>>>>>>task info
>>>>>>>rt_mutex_acquire 0
>>>>>>>Loop count: 0, Loop time: 355521102 ms rt_mutex_acquire 0 Loop
>count:
>>>>>>>1, Loop time: 355521103 ms rt_mutex_acquire 0 Loop count: 2, Loop
>>>>>>>time: 355521104 ms rt_mutex_acquire 0 Loop count: 3, Loop time:
>>>>>>>355521105 ms rt_mutex_acquire 0 Loop count: 4, Loop time:
>>>>>>>355521106 ms rt_mutex_acquire 0 Loop count: 5, Loop time:
>>>>>>>355521107 ms rt_mutex_acquire 0 Loop count: 6, Loop time:
>>>>>>>355521108 ms rt_mutex_acquire 0 Loop count: 7, Loop time:
>>>>>>>355521109 ms rt_mutex_acquire 0 Loop count: 8, Loop time:
>>>>>>>355521110 ms rt_mutex_acquire 0
>>>>>>>
>>>>>>>
>>>>>>>void loop_task_proc(void *arg) {
>>>>>>>
>>>>>>>        int cnt = 0;
>>>>>>>        int ret = 0 ;
>>>>>>>
>>>>>>>        RTIME tstart1;
>>>>>>>
>>>>>>>        RT_MUTEX            m_tMutex;
>>>>>>>//      RT_SEM              m_tSemaphore;
>>>>>>>        ret = rt_mutex_create(&m_tMutex, "test");
>>>>>>>        rt_printf("rt_mutex_create %d\n", ret ) ;
>>>>>>>
>>>>>>>//      ret = rt_sem_create(&m_tSemaphore, "test", 1, S_FIFO);
>>>>>>>//      rt_printf("rt_sem_create %d\n", ret ) ;
>>>>>>>
>>>>>>>        //Print the info
>>>>>>>        rt_printf("task info \n");
>>>>>>>
>>>>>>>        rt_task_set_periodic(NULL, TM_NOW, LOOP_PERIOD);
>>>>>>>
>>>>>>>
>>>>>>>        //Start the task loop
>>>>>>>        while (1) {
>>>>>>>        ret =   rt_mutex_acquire(&m_tMutex, TM_INFINITE );
>>>>>>>        rt_printf("rt_mutex_acquire %d\n", ret ) ;
>>>>>>>
>>>>>>>//      rt_sem_p(&m_tSemaphore, TM_INFINITE ) ;
>>>>>>>//      rt_printf("rt_sem_p %d\n", ret ) ;
>>>>>>>//
>>>>>>>        tstart1 = rt_timer_read () ;
>>>>>>>        rt_printf("Loop count: %d, Loop time: %llu ms\n", cnt,
>>>>>>>tstart1 /
>>>>>>1000000 );
>>>>>>>        cnt++;
>>>>>>>        rt_task_wait_period(NULL);
>>>>>>>
>>>>>>>//      ret =           rt_mutex_release(&m_tMutex);
>>>>>>>//      rt_printf("rt_mutex_release %d\n", ret ) ;
>>>>>>>//      rt_sem_v(&m_tSemaphore);
>>>>>>>//      rt_printf("rt_sem_v %d\n", ret ) ;
>>>>>>>        }
>>>>>>>}
>>>>>>>
>>>>>>>int main(int argc, char* argv[])
>>>>>>>{
>>>>>>>
>>>>>>>        RT_TASK loop_task;
>>>>>>>        rt_task_create(&loop_task, "basicmath_small", 0, 50, 0);
>>>>>>>        rt_task_start(&loop_task, &loop_task_proc, 0);
>>>>>>>        //Wait for Ctrl-C
>>>>>>>        pause();
>>>>>>>        return 0;
>>>>>>>
>>>>>>>
>>>>>>>}
>>>>>>>
>>>>>>>Thanks.
>>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>>>>Sent: Wednesday, October 26, 2022 11:43 AM
>>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>>xenomai@xenomai.org
>>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>;
>>>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>>>두산로보틱스
>>>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>>>두산로보틱스
>>>>>>><sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>>>>>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>>두산로보틱스
>>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>>>두산로보틱스
>>>>>>><sangjoon.kim@doosan.com>; 김동주(Dongjoo
>>>>>>>Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>
>>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>>
>>>>>>>I'm dong joo.
>>>>>>>
>>>>>>>I have a basic question.
>>>>>>>
>>>>>>>If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI
>>>Processor
>>>>>>>CONFIG, We can't check the current cpu freq by sysnode.
>>>>>>>
>>>>>>>Because, sysnode of cpu freq is related to CPU_FREQ CONFIG and
>>>>>>>ACPI Processor CONFIG as i know.
>>>>>>>
>>>>>>>
>>>>>>>If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI
>>>Processor
>>>>>>>CONFIG, Could you expect the current cpu freq in the intel hw system ?
>>>>>>>
>>>>>>>Actually, The minimum cpu clock of our hw system is very low.
>>>>>>>
>>>>>>>If our hw system operate with minimum cpu clock always, I worry
>>>>>>>about the performance of hw system.
>>>>>>>
>>>>>>>
>>>>>>>sys/devices/system/cpu/cpu0/cpufreq# ls affected_cpus
>>>>>>>cpuinfo_cur_freq  cpuinfo_min_freq
>>>>freqdomain_cpus
>>>>>>>scaling_available_frequencies  scaling_cur_freq  scaling_governor
>>>>>>>scaling_min_freq  stats
>>>>>>>bios_limit     cpuinfo_max_freq  cpuinfo_transition_latency
>>related_cpus
>>>>>>>scaling_available_governors    scaling_driver    scaling_max_freq
>>>>>>>scaling_setspeed
>>>>>>>
>>>>>>>
>>>>>>>Thanks.
>>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>>>>Sent: Tuesday, October 25, 2022 5:24 PM
>>>>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>;
>>>>>>>xenomai@xenomai.org
>>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>;
>>>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>>>두산로보틱스
>>>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>>>두산로보틱스
>>>>>>><sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무 두산로보틱스
>>>>>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>>두산로보틱스
>>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>>>두산로보틱스
>>>>>>><sangjoon.kim@doosan.com>
>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>
>>>>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일
>열람
>>>시
>>>>>>주의하시기 바랍니다.
>>>>>>>
>>>>>>>CAUTION: This email is sent by an external account. Please take
>>>>>>>extra caution when clicking the link or opening the attachment.
>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>
>>>>>>>>Sent: Tuesday, October 25, 2022 3:29 PM
>>>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>>>xenomai@xenomai.org
>>>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>>><youngchul3.park@doosan.com>;
>>>>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>>>>두산로보틱스
>>>>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>>>>두산로보틱스
>>>>>>>><sehyun2.kim@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>>>>>>두산로보틱스
>>>>>>>><dongjoo5.kim@doosan.com>; 이재석(Jaesuk Lee) 상무
>>두산로보틱스
>>>>>>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>>>두산로보틱스
>>>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon
>>>>>>>>Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>
>>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>>
>>>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>>>
>>>>>>>>I'm dong joo.
>>>>>>>>
>>>>>>>>After we do a aging test as like latency, We get a system hang
>>>>>>>>about ten hours later.
>>>>>>>>
>>>>>>>>At that time, Our system don't detect usb mouse.
>>>>>>>>
>>>>>>>>After rebooting our system by force, there is no significative
>>>>>>>>log in the kernel log or syslog.
>>>>>>>>
>>>>>>>>Could you help to us how to solve this issue ?
>>>>>>>
>>>>>>>Just as mentioned as in https://secure-
>>>>>>>web.cisco.com/1ll9UQp4RYnYXuVMxAlJKaDxV1RdMZtBcG3e_jDi4TlIxD
>>M
>>>Tz
>>>>F
>>>>>>M
>>>>>>>tJguJhndpS2BnNhGoAWwBP-G2UCWlarucvId1iz_ea_AU-
>>>>>>>U__8Gq6ZgF285KW8SRPHKr7NeWgE4dKG8o8PGMNJ3-
>>>>>>>lAB4xdptdPAk1vfJe8AL_Tt6oCEoT0OAr4RrSIjzqtmugt8EHD-
>>>>>>>jvxghKHjaWu1eGDkzOYtKpcV8WhZnz1wLItIZdChYT1xlXsFTU7-
>>>>>>>GnJhN2jLvMMlZgkMxzQLejJ2aB1wogBTkBIipva21mNGaSFb_sSZhX9ycwi
>T
>>7
>>>>U
>>>>>M
>>>>>>>UfQg5lyHCPZPEeP6/https%3A%2F%2Fxenomai.org%2Fpipermail%2Fxe
>n
>>o
>>>>m
>>>>>ai%
>>>>>>>2F2022-April%2F047495.html
>>>>>>>1. It is highly recommended to use a UART as kernel debug output.
>>>>>>>2. enable CONFIG_XENO_OPT_WATCHDOG for xenomai, system will be
>>>>able
>>>>>>to
>>>>>>>tell RT application "hangs" (infinite loop at high prio) apart
>>>>>>>from real hangs/crashes.
>>>>>>>
>>>>>>>Regards
>>>>>>>
>>>>>>>Hongzhan Chen
>>>>>>>>
>>>>>>>>
>>>>>>>>We set up our system as like below sw.
>>>>>>>>
>>>>>>>>1. Xubuntu 18.04 LTS 32bit
>>>>>>>>
>>>>>>>>2. Linux kernel 4.1.18 32bit
>>>>>>>>
>>>>>>>>3. Xenomai 3.0.8 32bit
>>>>>>>>
>>>>>>>>4. Kernel config
>>>>>>>>   We refer to the xenomai page as like below.
>>>>>>>>
>>>>>>>>https://secure-
>>>>>>>web.cisco.com/1nAW3bSL64gGRUPlQWKtShagcypkiReyVX7nhG1T-J
>>>>>>>>upEWaqU-3hnCSt542V_mEwX-
>>>>>>>_8HsjCaWtSuQnJ3056Yq52DypR5psiqKgrOSq6pbk6xe-tw
>>>>>>>>xYZhwwm0akkU4iVwFscbrRTWdk2Ul-
>>>>>>>9fU2HilSTJ8rzI8X9LIfFg2foor5t9LawggXyjgq3
>>>>>>>>QqwJktjRWEhqL8gFDP2PpsmxrTgVK6NzJdcBxzyOGo_jmjjiO009l74YL2
>U
>>5
>>>K
>>>>e
>>>>>3
>>>>>>A
>>>>>>>7kc1AX7
>>>>>>>>IV_t016CRGEK4QyAKRuSTqKzFm8t4flDV7eBT4m43w-o_SoFrKq-
>>>>>>>AA7ZIKEYPEgpqq/http
>>>>>>>>s%3A%2F%2Fsource.denx.de%2FXenomai%2Fxenomai%2F-
>>>>>>>>/wikis/Configuring_For_X86_Based_Dual_Kernels#user-content-x86-
>>>>>>>>processor-type
>>>>>>>>
>>>>>>>>Thanks.
>>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>>>>>Sent: Friday, August 26, 2022 2:40 PM
>>>>>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>;
>>>>>>>>xenomai@xenomai.org
>>>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>>><youngchul3.park@doosan.com>;
>>>>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>>>>두산로보틱스
>>>>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>>>>두산로보틱스
>>>>>>>><sehyun2.kim@doosan.com>
>>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>>
>>>>>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일
>>열람
>>>>시
>>>>>>>주의하시기 바랍니다.
>>>>>>>>
>>>>>>>>CAUTION: This email is sent by an external account. Please take
>>>>>>>>extra caution when clicking the link or opening the attachment.
>>>>>>>>
>>>>>>>>>-----Original Message-----
>>>>>>>>>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>>>>>>>>>Sent: Friday, August 26, 2022 10:41 AM
>>>>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>>>>xenomai@xenomai.org
>>>>>>>>>Cc: ???(Youngchul Park) ????? ??????
>>>>>>>><youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ??????
>>>>>>>><kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ??????
>>>>>>>><sehyun2.kim@doosan.com>; ???(Dongjoo Kim) ????? ??????
>>>>>>>><dongjoo5.kim@doosan.com>
>>>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>>>
>>>>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>>>>
>>>>>>>>>I'm dong joo.
>>>>>>>>>
>>>>>>>>>Thank you for your reply to us our questions.
>>>>>>>>>
>>>>>>>>>And, We have checked the value of TICK_NSEC int our system.
>>>>>>>>>
>>>>>>>>>#define TICK_NSEC ((NSEC_PER_SEC+HZ/2)/HZ)
>>>>>>>>>#define NSEC_PER_SEC   1000000000L
>>>>>>>>>HZ  250 ( Max 1000 )
>>>>>>>>>
>>>>>>>>>The value of TICK_NSEC is defined by linux kernel.
>>>>>>>>>And, Both NSEC_PER_SEC and HZ calculate the value of TICK_NSEC.
>>>>>>>>>
>>>>>>>>>So, The current value of TICK_NSEC is 4ms based on 250 HZ.
>>>>>>>>>And, If we change the value of HZ to 1000, The value of
>>>>>>>>>TICK_NSEC may be
>>>>>>>>1ms.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>We hope to process a task every 20us using rt_task_yield as
>>>>>>>>>like Xenomai
>>>>>>>>2.6.5.
>>>>>>>>>
>>>>>>>>>Is there any method to achieve 20us task delay using
>>>>>>>>>rt_task_yield or another
>>>>>>>>xenomai method ?
>>>>>>>>>And, Is there any problem to reduce the delay more less than
>>>>TICK_NSEC ?
>>>>>>>>
>>>>>>>>I just went through the implementation of rt_task_yield of
>>>>>>>>Xeomai
>>>>>>>>2.6.5 and found that it is totally different from Xenomai 3.0.8.
>>>>>>>>If you want to yield about 20us for current RT thread ,you may
>>>>>>>>try call clock_nanosleep .
>>>>>>>>.
>>>>>>>>Regards
>>>>>>>>
>>>>>>>>Hongzhan Chen
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>Really Thanks.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>This e-mail and any attachments herein may contain confidential
>>>>>>>>or privileged information and is for the exclusive use of the
>>>>>>>>intended
>>>>>>>>recipient(s) named above. If you are not the intended
>>>>>>>>recipient(s), you should not disseminate, distribute, retain,
>>>>>>>>copy or otherwise use any information contained herein. If you
>>>>>>>>have received this e-mail in error, please notify the sender
>>>>>>>>immediately by replying to this message and
>>>>>>>delete this e-mail and associated attachments.
>>>>>>>>Our company does not guarantee this e-mail is secure or free
>>>>>>>>from
>>>>viruses.
>>>>>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>>>>>포함하고
>>>>>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>>>>>>용도로도 이를
>>>>>>>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>>>>>>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>>>>>>>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>>>>>>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>>>>>>>
>>>>>>>
>>>>>>>This e-mail and any attachments herein may contain confidential
>>>>>>>or privileged information and is for the exclusive use of the
>>>>>>>intended
>>>>>>>recipient(s) named above. If you are not the intended
>>>>>>>recipient(s), you should not disseminate, distribute, retain,
>>>>>>>copy or otherwise use any information contained herein. If you
>>>>>>>have received this e-mail in error, please notify the sender
>>>>>>>immediately by replying to this message and
>>>>>>delete this e-mail and associated attachments.
>>>>>>>Our company does not guarantee this e-mail is secure or free from
>>>viruses.
>>>>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>>>>포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>>>>용도로도 이를
>>>>>>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>>>>>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>>>>>>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>>>>>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>>>>>>
>>>>>>
>>>>>>This e-mail and any attachments herein may contain confidential or
>>>>>privileged
>>>>>>information and is for the exclusive use of the intended
>>>>>>recipient(s) named above. If you are not the intended
>>>>>>recipient(s), you should not disseminate, distribute, retain, copy
>>>>>>or otherwise use any information contained herein. If you have
>>>>>>received this e-mail in error, please notify the sender
>>>>>>immediately
>>>>>by
>>>>>>replying to this message and delete this e-mail and associated
>>attachments.
>>>>>>Our company does not guarantee this e-mail is secure or free from
>>viruses.
>>>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>>>포함하고
>>>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>>>>용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로
>>>>>>발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을
>>>>알려 드립니다. 잘못
>>>>>수신하신
>>>>>>경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>>>>
>>>>
>>>>This e-mail and any attachments herein may contain confidential or
>>>privileged
>>>>information and is for the exclusive use of the intended
>>>>recipient(s) named above. If you are not the intended recipient(s),
>>>>you should not disseminate, distribute, retain, copy or otherwise
>>>>use any information contained herein. If you have received this
>>>>e-mail in error, please notify the sender immediately
>>>by
>>>>replying to this message and delete this e-mail and associated attachments.
>>>>Our company does not guarantee this e-mail is secure or free from viruses.
>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>포함하고
>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>>용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로
>>>>발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을
>>알려 드립니다. 잘못
>>>수신하신
>>>>경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기
>>>>바랍니다. 협조에 감사 드립니다.
>>
>>
>>This e-mail and any attachments herein may contain confidential or
>>privileged information and is for the exclusive use of the intended
>>recipient(s) named above. If you are not the intended recipient(s),
>>you should not disseminate, distribute, retain, copy or otherwise use
>>any information contained herein. If you have received this e-mail in
>>error, please notify the sender immediately by replying to this
>>message and
>delete this e-mail and associated attachments.
>>Our company does not guarantee this e-mail is secure or free from viruses.
>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를
>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>
>
>This e-mail and any attachments herein may contain confidential or
>privileged information and is for the exclusive use of the intended
>recipient(s) named above. If you are not the intended recipient(s), you
>should not disseminate, distribute, retain, copy or otherwise use any
>information contained herein. If you have received this e-mail in
>error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments.
>Our company does not guarantee this e-mail is secure or free from viruses.
>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한
>수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.


This e-mail and any attachments herein may contain confidential or privileged information and is for the exclusive use of the intended recipient(s) named above. If you are not the intended recipient(s), you should not disseminate, distribute, retain, copy or otherwise use any information contained herein. If you have received this e-mail in error, please notify the sender immediately by replying to this message and delete this e-mail and associated attachments. Our company does not guarantee this e-mail is secure or free from viruses.
이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.

RE: What causes the latency of the rt_task_yield() API?

[Chen, Hongzhan]

>-----Original Message-----
>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>
>Sent: Monday, January 30, 2023 9:36 AM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim)
>수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>; 이형석(Hyungseok
>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song) 책임연구원 두산로보틱스
><changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원
>두산로보틱스 <kyungchan.son@doosan.com>; 김동주(Dongjoo Kim)
>책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>Dear Xenomai.org, Chen, Hongzhan
>
>I'm dong joo.
>
>I'm really thanks for your support.
>
>We have a critical issue, but I can't find any solution.
>
>
>If we run  our system for long run test,
>Xenomai watchdog signal to our BTask after 8~10 hours as like below.
>
>
>[Xenomai] watchdog triggered on CPU #2 -- runaway thread ' Btask ' signale
>
>
>
>Our BTask just call A function every 1ms.
>So, I have checked the time between before A function and after A function
>using rt_printf.
>
>I have checked all the rt_printf log. But, There is abnormal status.
>
>The processing time of A function is about 2us even though Xenomai
>watchdog signal to our BTask.
>
>
>How do we solve this problem?
>Could you help to us to debug this issue ?

When system leave root (linux domain), it start the watchdog timer. When it enter root(linux domain), it stop
the watdogtimer. When it is triggered , that means that in last 4s  cpu has been totally dominating by Xenomai domain( you rt threads).  You may like to enable tracing and enable cobalt_schedule and cobalt_trace and cobalt_switch_context and cobalt_trace_pid and cobalt_watchdog_signal events under /sys/kernel/debug/tracing/events/cobalt_core/ to debug out how many rt threads running on the cpu before watchdog is signaled. Is BTask the sole RT thread running on the cpu?  If not, you may need to cooperate them to
enter root for a while in 4s on the cpu to avoid triggering the watchdog.

Regards

Hongzhan Chen

>
>
>RT_TASK Btask;
>unsigned long long time2 = 0 ;
>unsinged long long time3 = 0 ;
>
>
>BThread ( void ( *pArg )
>{
>
>while (1)
>{
>        rt_task_sleep ( 1000000 );
>
>        time2= (rt_timer_read() / 1000 );
>        rt_printf(" time2 %llu\n",time2 ) ;
>        A func ();
>        time3= (rt_timer_read() / 1000 );
>        rt_printf(" time3 %llu\n",time3 ) ;
>}
>
>int main ( int argc, char * argv [] )
>{
>        cpu_set_t cpus ;
>        rt_task_create ( &BTask, "Btask", 8 * 1024 * 1024, PRIORITY_LOWLOW,
>T_JOINABLE);
>        CPU_ZERO(&cpus);
>        CPU_SET(2, &cpus);
>        rt_task_set_affinity(&BTask, &cpus);
>
>        rt_task_start(&BTask, &BThread, NULL);
>}
>
>
>Thanks.
>-----Original Message-----
>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>Sent: Monday, January 30, 2023 9:56 AM
>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원 두산로보틱스
><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스 <youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim)
>수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>; 이형석(Hyungseok
>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song) 책임연구원 두산로보틱스
><changwoo.song@doosan.com>; 손경찬(Kyungchan Son) 선임연구원
>두산로보틱스 <kyungchan.son@doosan.com>
>Subject: RE: What causes the latency of the rt_task_yield() API?
>
>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>주의하시기 바랍니다.
>
>CAUTION: This email is sent by an external account. Please take extra caution
>when clicking the link or opening the attachment.
>
>>-----Original Message-----
>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>
>>Sent: Wednesday, January 25, 2023 12:54 PM
>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스
>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>두산로보틱스
>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song) 책임연구원
>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>선임연구원 두산로보틱스
>><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>두산로보틱스
>><dongjoo5.kim@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>Dear Xenomai.org, Chen, Hongzhan
>>
>>I'm dong joo.
>>
>>I'm really thanks for your support.
>>
>>
>>We set the Watchdog timeout value for 4.
>>
>>Could you explain the unit of value ?
>>Is the value 4ms or 4s ?
>>
>>
>>[*]   Watchdog support
>>(4)     Watchdog timeout
>
>If you type 'h' on the focused "Watchdog timeout" during make menuconfig, it
>would pop up the description like following. It clearly say that is in seconds.
>
>x CONFIG_XENO_OPT_WATCHDOG_TIMEOUT:
>x
>  x
>x
>  x Watchdog timeout value (in seconds).
>x
>  x
>x
>  x Symbol: XENO_OPT_WATCHDOG_TIMEOUT [=4]
>  x Type  : integer
>x
>  x Range : [1 60]
>x
>  x Defined at kernel/xenomai/Kconfig:481
>x
>  x   Prompt: Watchdog timeout
>x
>  x   Depends on: XENOMAI [=y] && XENO_OPT_DEBUG [=y] &&
>XENO_OPT_WATCHDOG [=y]                                                                          x
>  x   Location:
>x
>  x     -> Xenomai/cobalt (XENOMAI [=y])
>x
>  x       -> Debug support (XENO_OPT_DEBUG [=y])
>x
>  x         -> Watchdog support (XENO_OPT_WATCHDOG [=y])
>
>Regards
>
>Hongzhan Chen
>
>>
>>
>>Thanks
>>
>>-----Original Message-----
>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>
>>Sent: Tuesday, January 17, 2023 2:46 PM
>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스
>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>두산로보틱스
>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song) 책임연구원
>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>선임연구원 두산로보틱스
>><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>두산로보틱스
>><dongjoo5.kim@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>Dear Xenomai.org, Chen, Hongzhan
>>
>>I'm dong joo.
>>
>>I'm really thanks for your support.
>>
>>
>>We set the Watchdog timeout value for 4.
>>
>>Could you explain the unit of value ?
>>Is the value 4ms or 4s ?
>>
>>
>>[*]   Watchdog support
>>(4)     Watchdog timeout
>>
>>
>>
>>Thanks
>>  -----Original Message-----
>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>Sent: Tuesday, January 17, 2023 11:03 AM
>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>두산로보틱스
>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>두산로보틱스
>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>두산로보틱스
>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>송창우(Changwoo Song) 책임연구원
>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>선임연구원 두산로보틱스
>><kyungchan.son@doosan.com>
>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>
>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>주의하시기 바랍니다.
>>
>>CAUTION: This email is sent by an external account. Please take extra
>>caution when clicking the link or opening the attachment.
>>
>>>-----Original Message-----
>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>><dongjoo5.kim@doosan.com>
>>>Sent: Tuesday, January 17, 2023 7:52 AM
>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@xenomai.org
>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>두산로보틱스
>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>두산로보틱스
>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>두산로보틱스
>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>송창우(Changwoo Song) 책임연구원
>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>>선임연구원 두산로보틱스
>>><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>두산로보틱스
>>><dongjoo5.kim@doosan.com>
>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>
>>>Dear Xenomai.org, Chen, Hongzhan
>>>
>>>I'm dong joo.
>>>
>>>I'm really thanks for your support.
>>>
>>>
>>>If we apply as like below functions, The error result is not same.
>>>Could you explain the difference between rt_task_sleep()and
>>
>>I am not familiar with alchemy skin, but from the implementation of
>>rt_task_sleep, we can see that it would also call clock_nanosleep when
>>you set timeout value but the clockid may be one of CLOCK_REALTIME and
>>CLOCK_MONOTONIC  which depends on your configuration, Please check
>>rt_task_sleep(lib/alchemy/task.c) -
>>>threadobj_sleep(lib/copperplate/threadobj.c )-> clock_nanosleep
>>
>>>clock_nanosleep() ?
>>>
>>>
>>>And, If our code run a cpu,
>>>Is there any possibility to act context switching by other process ?
>>
>>Of course.
>>
>>>
>>>
>>>Is the Xenomai Scheduler preemption or non- preemption ?
>>
>>Xenomai scheduler support preemption but depends on how you configure
>>schedule policy for your threads in real case.
>>
>>
>>>
>>>
>>>While ( 1 ) {
>>>
>>>rt_task_sleep(1000000 );
>>>
>>>our code start ;
>>>our cod end ;
>>>
>>>}
>>>
>>>: The result is segfault by our code.
>>>
>>>
>>>While ( 1 ) {
>>>
>>>struct timespec ts;
>>>      ts.tv_sec = 0;
>>>      ts.tv_nsec = 1000000; /* 1ms */
>>>
>>>clock_nanosleep(CLOCK_REALTIME, 0, &ts, NULL);
>>>
>>>our code start ;
>>>our cod end ;
>>>
>>>}
>>>
>>>: The result is Xenomai watchdog as like below.
>>>   by Xenomai/cobalt: watchdog triggered CPU time limit exceeded (core
>>>dumped)
>>
>>Watchdog triggered because Xenomai domain dominate the cpu too much
>>time.  Please check which Thread dominate cpu. In addition , you may
>>check /proc/xenomai/sched/threads or /proc/xenomai/sched/stat to find
>>out if there is multi RT threads running at that time. If there is
>>multi threads running , the cpu yielded by one of rt threads by
>>clock_nanosleep may be occupied by other RT threads which still be
>dominating CPU.
>>
>>Regards
>>
>>Hongzhan Chen
>>
>>>
>>>
>>>Thanks.
>>>-----Original Message-----
>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>Sent: Wednesday, January 11, 2023 12:14 AM
>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>두산로보틱스
>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>두산로보틱스
>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>두산로보틱스
>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>송창우(Changwoo Song) 책임연구원
>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>>선임연구원 두산로보틱스
>>><kyungchan.son@doosan.com>
>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>
>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람 시
>>주의하시기 바랍니다.
>>>
>>>CAUTION: This email is sent by an external account. Please take extra
>>>caution when clicking the link or opening the attachment.
>>>
>>>>-----Original Message-----
>>>>From: Chen, Hongzhan
>>>>Sent: Friday, January 6, 2023 10:36 AM
>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>>><youngchul3.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>두산로보틱스
>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>두산로보틱스
>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>두산로보틱스
>>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>송창우(Changwoo Song) 책임연구원
>>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>>>선임연구원 두산로보틱스
>>>><kyungchan.son@doosan.com>
>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>><dongjoo5.kim@doosan.com>
>>>>>Sent: Thursday, January 5, 2023 5:50 PM
>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>xenomai@xenomai.org
>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>;
>>>>>김세현(Sehyun Kim) 연구원
>>>>두산로보틱스
>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>두산로보틱스
>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>두산로보틱스
>>>>><sangjoon.kim@doosan.com>;
>>>>이형석(Hyungseok
>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>송창우(Changwoo Song)
>>>>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>;
>>>손경찬(Kyungchan Son) 선임연구원
>>>>>두산로보틱스 <kyungchan.son@doosan.com>; 김동주(Dongjoo Kim)
>>>책임연구원 두산로보틱스
>>>>><dongjoo5.kim@doosan.com>
>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>
>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>
>>>>>I'm dong joo.
>>>>>
>>>>>I'm really thanks for your support.
>>>>>
>>>>>
>>>>>If we test a rt_mutex_create, rt_mutex_acquire, rt_mutex_release
>>>>>with Xenomai 2.6.5, The test result is same to Xenomai 3.
>>>>>
>>>>>Even though we disable rt_mutex_release API, the count increase
>>>>>increase abnormally.
>>>>>
>>>>>Is the result normal case or not ?
>>>>>
>>>>>Could you share to us the comment about the result ?
>>>>
>>>>Following is the mutex description. When the mutex is owned by
>>>>current task, it always can enter critical sections but just block
>>>>any other task per my understanding.
>>>>
>>>>Mutex services.
>>>>A mutex is a MUTual EXclusion object, and is useful for protecting
>>>>shared data structures from concurrent modifications, and
>>>>implementing critical sections and monitors.
>>>>
>>>>A mutex has two possible states: unlocked (not owned by any task),
>>>>and locked (owned by one task). A mutex can never be owned by two
>>>>different tasks simultaneously. A task attempting to lock a mutex
>>>>that is already locked by another task is blocked until the latter
>>>>unlocks the
>>mutex first.
>>>>
>>>>Xenomai mutex services enforce a priority inheritance protocol in
>>>>order to solve priority inversions.
>>>
>>>The implementation of rt_mutex_create set PTHREAD_MUTEX_RECURSIVE
>>>attribution by default for the mutex, so the same thread can have
>>>multi lock but avoid deadlock.
>>>
>>>Regards
>>>
>>>Hongzhan Chen
>>>
>>>>
>>>>Regards
>>>>
>>>>Hongzhan Chen
>>>>>
>>>>>Thanks.
>>>>>-----Original Message-----
>>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>>Sent: Thursday, January 5, 2023 6:41 PM
>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>; 김동주(Dongjoo Kim)
>>>책임연구원
>>>>>두산로보틱스 <dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
><youngchul3.park@doosan.com>;
>>>>>김세현(Sehyun Kim) 연구원
>>>>두산로보틱스
>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>두산로보틱스
>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>두산로보틱스
>>>>><sangjoon.kim@doosan.com>;
>>>>이형석(Hyungseok
>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>송창우(Changwoo Song)
>>>>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>;
>>>손경찬(Kyungchan Son) 선임연구원
>>>>>두산로보틱스 <kyungchan.son@doosan.com>
>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>
>>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일 열람
>시
>>>주의하시기 바랍니다.
>>>>>
>>>>>CAUTION: This email is sent by an external account. Please take
>>>>>extra caution when clicking the link or opening the attachment.
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>>>Sent: Thursday, January 5, 2023 5:25 PM
>>>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>><youngchul3.park@doosan.com>;
>>>>>>김세현(Sehyun Kim) 연구원
>>>>>두산로보틱스
>>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>두산로보틱스
>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>>두산로보틱스
>>>>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>>>송창우(Changwoo Song) 책임연구원
>>>>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan Son)
>>>>>선임연구원 두산로보틱스
>>>>>><kyungchan.son@doosan.com>
>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>
>>>>>>
>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>
>>>>>>>Sent: Thursday, January 5, 2023 3:18 PM
>>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>>xenomai@xenomai.org
>>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>;
>>>>>>>김세현(Sehyun Kim) 연구원
>>>>>>두산로보틱스
>>>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>두산로보틱스
>>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>>두산로보틱스
>>>>>>><sangjoon.kim@doosan.com>;
>>>>>>이형석(Hyungseok
>>>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>>>송창우(Changwoo Song)
>>>>>>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>;
>>>>>손경찬(Kyungchan Son) 선임연구원
>>>>>>>두산로보틱스 <kyungchan.son@doosan.com>; 김동주(Dongjoo Kim)
>>>>>책임연구원 두산로보틱스
>>>>>>><dongjoo5.kim@doosan.com>
>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>
>>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>>
>>>>>>>I'm dong joo.
>>>>>>>
>>>>>>>Thanks for your support.
>>>>>>>
>>>>>>>I have one more questions.
>>>>>>>
>>>>>>>Is the posix-mutex realtime mutex or not ?
>>>>>>
>>>>>>Yes, it is realtime.
>>>>>>
>>>>>>>
>>>>>>>And, Is there no problem to use the posix-mutex in the realtime Task ?
>>>>>>
>>>>>>No, I do not think there is problem to use posix-mutex in realttime
>>>>>>task. You can see that posix mutex  test already be covered in each
>>>>>>release as one of smokey test.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>Finally, Is there any problem to use the rt_mutex_lock based on
>>>>>>>Xenomai guide?
>>>>>>
>>>>>>From Xenomai 3 , all alchemy APIs such as rt_mutex_* actually is
>>>>>>based on posix API, which is quite different from Xenomai 2.
>>>>>
>>>>>According to doc/asciidoc/MIGRATION.adoc,
>>>>>
>>>>>- Like +rt_mutex_inquire()+, +rt_cond_inquire()+ does not return the
>>>>>count
>>>>of
>>>>>waiting tasks anymore.
>>>>>
>>>>>Regards
>>>>>
>>>>>Hongzhan Chen
>>>>>>
>>>>>>Regards
>>>>>>
>>>>>>Hongzhan Chen
>>>>>>>
>>>>>>>
>>>>>>>Thanks.
>>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>>>>Sent: Thursday, January 5, 2023 4:03 PM
>>>>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>>>><dongjoo5.kim@doosan.com>; xenomai@xenomai.org
>>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>;
>>>>>>>김세현(Sehyun Kim) 연구원
>>>>>>두산로보틱스
>>>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>두산로보틱스
>>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>>두산로보틱스
>>>>>>><sangjoon.kim@doosan.com>;
>>>>>>이형석(Hyungseok
>>>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>>>송창우(Changwoo Song)
>>>>>>>책임연구원 두산로보틱스 <changwoo.song@doosan.com>;
>>>>>손경찬(Kyungchan Son) 선임연구원
>>>>>>>두산로보틱스 <kyungchan.son@doosan.com>
>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>
>>>>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일
>열람
>>>시
>>>>>주의하시기 바랍니다.
>>>>>>>
>>>>>>>CAUTION: This email is sent by an external account. Please take
>>>>>>>extra caution when clicking the link or opening the attachment.
>>>>>>>
>>>>>>>Hi
>>>>>>>
>>>>>>>Why do not you use posix mutex like example in
>>>>>>>testsuite/smokey/posix- mutex/posix-mutex.c?
>>>>>>>
>>>>>>>
>>>>>>>Regards
>>>>>>>
>>>>>>>Hongzhan Chen
>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>><dongjoo5.kim@doosan.com>
>>>>>>>>Sent: Thursday, January 5, 2023 9:21 AM
>>>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>>>xenomai@xenomai.org
>>>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>;
>>>>>>>>김세현(Sehyun Kim) 연구원
>>>>>>>두산로보틱스
>>>>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>>>두산로보틱스
>>>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>>>>두산로보틱스
>>>>>>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>>>>>송창우(Changwoo Song) 책임연구원
>>>>>>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan
>>Son)
>>>>>>>선임연구원 두산로보틱스
>>>>>>>><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>>>>>>두산로보틱스
>>>>>>>><dongjoo5.kim@doosan.com>
>>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>>
>>>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>>>
>>>>>>>>I'm dong joo.
>>>>>>>>
>>>>>>>>Could you help me to solve this problem ?
>>>>>>>>
>>>>>>>>Thanks.
>>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>><dongjoo5.kim@doosan.com>
>>>>>>>>Sent: Monday, January 2, 2023 12:10 PM
>>>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>>>xenomai@xenomai.org
>>>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>;
>>>>>>>>김세현(Sehyun Kim) 연구원
>>>>>>>두산로보틱스
>>>>>>>><sehyun2.kim@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>>>두산로보틱스
>>>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>>>>두산로보틱스
>>>>>>>><sangjoon.kim@doosan.com>; 이형석(Hyungseok
>>>>>>>>Lee) 주임연구원 두산로보틱스 <hyungseok3.lee@doosan.com>;
>>>>>>>송창우(Changwoo Song) 책임연구원
>>>>>>>>두산로보틱스 <changwoo.song@doosan.com>; 손경찬(Kyungchan
>>Son)
>>>>>>>선임연구원 두산로보틱스
>>>>>>>><kyungchan.son@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>>>>>>두산로보틱스
>>>>>>>><dongjoo5.kim@doosan.com>
>>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>>
>>>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>>>
>>>>>>>>I'm dong joo.
>>>>>>>>
>>>>>>>>We have tested the API of Xenomai rt_mutex as like
>>>>>>>>rt_mutex_create, rt_mutex_acquire, rt_mutex_release.
>>>>>>>>
>>>>>>>>
>>>>>>>>If we block the rt_mutex_release, The next sequence can't get a
>>>>>>>>rt_mutex_acquire by the previous sequence don't call
>>>>>>>>rt_mutex_release before.
>>>>>>>>
>>>>>>>>So, The result of count must be 0 what we think.
>>>>>>>>
>>>>>>>>But, The result of count increase abnormally as like below. Is
>>>>>>>>there any problem about rt_mutex_acquire or rt_mutex_release ?
>>>>>>>>
>>>>>>>>
>>>>>>>>If we test the API of Xenomai rt_sem as like rt_sem_create,
>>>>>>>>rt_sem_p, rt_sem_v, The result of count is 0.
>>>>>>>>
>>>>>>>>
>>>>>>>>rt_mutex_create 0
>>>>>>>>task info
>>>>>>>>rt_mutex_acquire 0
>>>>>>>>Loop count: 0, Loop time: 355521102 ms rt_mutex_acquire 0 Loop
>>count:
>>>>>>>>1, Loop time: 355521103 ms rt_mutex_acquire 0 Loop count: 2, Loop
>>>>>>>>time: 355521104 ms rt_mutex_acquire 0 Loop count: 3, Loop time:
>>>>>>>>355521105 ms rt_mutex_acquire 0 Loop count: 4, Loop time:
>>>>>>>>355521106 ms rt_mutex_acquire 0 Loop count: 5, Loop time:
>>>>>>>>355521107 ms rt_mutex_acquire 0 Loop count: 6, Loop time:
>>>>>>>>355521108 ms rt_mutex_acquire 0 Loop count: 7, Loop time:
>>>>>>>>355521109 ms rt_mutex_acquire 0 Loop count: 8, Loop time:
>>>>>>>>355521110 ms rt_mutex_acquire 0
>>>>>>>>
>>>>>>>>
>>>>>>>>void loop_task_proc(void *arg) {
>>>>>>>>
>>>>>>>>        int cnt = 0;
>>>>>>>>        int ret = 0 ;
>>>>>>>>
>>>>>>>>        RTIME tstart1;
>>>>>>>>
>>>>>>>>        RT_MUTEX            m_tMutex;
>>>>>>>>//      RT_SEM              m_tSemaphore;
>>>>>>>>        ret = rt_mutex_create(&m_tMutex, "test");
>>>>>>>>        rt_printf("rt_mutex_create %d\n", ret ) ;
>>>>>>>>
>>>>>>>>//      ret = rt_sem_create(&m_tSemaphore, "test", 1, S_FIFO);
>>>>>>>>//      rt_printf("rt_sem_create %d\n", ret ) ;
>>>>>>>>
>>>>>>>>        //Print the info
>>>>>>>>        rt_printf("task info \n");
>>>>>>>>
>>>>>>>>        rt_task_set_periodic(NULL, TM_NOW, LOOP_PERIOD);
>>>>>>>>
>>>>>>>>
>>>>>>>>        //Start the task loop
>>>>>>>>        while (1) {
>>>>>>>>        ret =   rt_mutex_acquire(&m_tMutex, TM_INFINITE );
>>>>>>>>        rt_printf("rt_mutex_acquire %d\n", ret ) ;
>>>>>>>>
>>>>>>>>//      rt_sem_p(&m_tSemaphore, TM_INFINITE ) ;
>>>>>>>>//      rt_printf("rt_sem_p %d\n", ret ) ;
>>>>>>>>//
>>>>>>>>        tstart1 = rt_timer_read () ;
>>>>>>>>        rt_printf("Loop count: %d, Loop time: %llu ms\n", cnt,
>>>>>>>>tstart1 /
>>>>>>>1000000 );
>>>>>>>>        cnt++;
>>>>>>>>        rt_task_wait_period(NULL);
>>>>>>>>
>>>>>>>>//      ret =           rt_mutex_release(&m_tMutex);
>>>>>>>>//      rt_printf("rt_mutex_release %d\n", ret ) ;
>>>>>>>>//      rt_sem_v(&m_tSemaphore);
>>>>>>>>//      rt_printf("rt_sem_v %d\n", ret ) ;
>>>>>>>>        }
>>>>>>>>}
>>>>>>>>
>>>>>>>>int main(int argc, char* argv[])
>>>>>>>>{
>>>>>>>>
>>>>>>>>        RT_TASK loop_task;
>>>>>>>>        rt_task_create(&loop_task, "basicmath_small", 0, 50, 0);
>>>>>>>>        rt_task_start(&loop_task, &loop_task_proc, 0);
>>>>>>>>        //Wait for Ctrl-C
>>>>>>>>        pause();
>>>>>>>>        return 0;
>>>>>>>>
>>>>>>>>
>>>>>>>>}
>>>>>>>>
>>>>>>>>Thanks.
>>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>>>>>>>Sent: Wednesday, October 26, 2022 11:43 AM
>>>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>>>xenomai@xenomai.org
>>>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>;
>>>>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>>>>두산로보틱스
>>>>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>>>>두산로보틱스
>>>>>>>><sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무
>두산로보틱스
>>>>>>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>>>두산로보틱스
>>>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>>>>두산로보틱스
>>>>>>>><sangjoon.kim@doosan.com>; 김동주(Dongjoo
>>>>>>>>Kim) 책임연구원 두산로보틱스 <dongjoo5.kim@doosan.com>
>>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>>
>>>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>>>
>>>>>>>>I'm dong joo.
>>>>>>>>
>>>>>>>>I have a basic question.
>>>>>>>>
>>>>>>>>If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI
>>>>Processor
>>>>>>>>CONFIG, We can't check the current cpu freq by sysnode.
>>>>>>>>
>>>>>>>>Because, sysnode of cpu freq is related to CPU_FREQ CONFIG and
>>>>>>>>ACPI Processor CONFIG as i know.
>>>>>>>>
>>>>>>>>
>>>>>>>>If we disable CPU_FREQ CONFIG and CPU_IDLE CONFIG and ACPI
>>>>Processor
>>>>>>>>CONFIG, Could you expect the current cpu freq in the intel hw system ?
>>>>>>>>
>>>>>>>>Actually, The minimum cpu clock of our hw system is very low.
>>>>>>>>
>>>>>>>>If our hw system operate with minimum cpu clock always, I worry
>>>>>>>>about the performance of hw system.
>>>>>>>>
>>>>>>>>
>>>>>>>>sys/devices/system/cpu/cpu0/cpufreq# ls affected_cpus
>>>>>>>>cpuinfo_cur_freq  cpuinfo_min_freq
>>>>>freqdomain_cpus
>>>>>>>>scaling_available_frequencies  scaling_cur_freq  scaling_governor
>>>>>>>>scaling_min_freq  stats
>>>>>>>>bios_limit     cpuinfo_max_freq  cpuinfo_transition_latency
>>>related_cpus
>>>>>>>>scaling_available_governors    scaling_driver    scaling_max_freq
>>>>>>>>scaling_setspeed
>>>>>>>>
>>>>>>>>
>>>>>>>>Thanks.
>>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>>>>>Sent: Tuesday, October 25, 2022 5:24 PM
>>>>>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
><dongjoo5.kim@doosan.com>;
>>>>>>>>xenomai@xenomai.org
>>>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>><youngchul3.park@doosan.com>;
>>>>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>>>>두산로보틱스
>>>>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>>>>두산로보틱스
>>>>>>>><sehyun2.kim@doosan.com>; 이재석(Jaesuk Lee) 상무
>두산로보틱스
>>>>>>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>>>두산로보틱스
>>>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon Kim) 수석연구원
>>>>>>>두산로보틱스
>>>>>>>><sangjoon.kim@doosan.com>
>>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>>
>>>>>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일
>>열람
>>>>시
>>>>>>>주의하시기 바랍니다.
>>>>>>>>
>>>>>>>>CAUTION: This email is sent by an external account. Please take
>>>>>>>>extra caution when clicking the link or opening the attachment.
>>>>>>>>
>>>>>>>>>-----Original Message-----
>>>>>>>>>From: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>>><dongjoo5.kim@doosan.com>
>>>>>>>>>Sent: Tuesday, October 25, 2022 3:29 PM
>>>>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>>>>xenomai@xenomai.org
>>>>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>>>><youngchul3.park@doosan.com>;
>>>>>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>>>>>두산로보틱스
>>>>>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>>>>>두산로보틱스
>>>>>>>>><sehyun2.kim@doosan.com>; 김동주(Dongjoo Kim) 책임연구원
>>>>>>>>두산로보틱스
>>>>>>>>><dongjoo5.kim@doosan.com>; 이재석(Jaesuk Lee) 상무
>>>두산로보틱스
>>>>>>>>><jaesuk.lee@doosan.com>; 이영재(Youngjae Lee) 주임연구원
>>>>>>>>두산로보틱스
>>>>>>>>><youngjae7.lee@doosan.com>; 김상준(Sangjoon
>>>>>>>>>Kim) 수석연구원 두산로보틱스 <sangjoon.kim@doosan.com>
>>>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>>>
>>>>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>>>>
>>>>>>>>>I'm dong joo.
>>>>>>>>>
>>>>>>>>>After we do a aging test as like latency, We get a system hang
>>>>>>>>>about ten hours later.
>>>>>>>>>
>>>>>>>>>At that time, Our system don't detect usb mouse.
>>>>>>>>>
>>>>>>>>>After rebooting our system by force, there is no significative
>>>>>>>>>log in the kernel log or syslog.
>>>>>>>>>
>>>>>>>>>Could you help to us how to solve this issue ?
>>>>>>>>
>>>>>>>>Just as mentioned as in https://secure-
>>>>>>>>web.cisco.com/1ll9UQp4RYnYXuVMxAlJKaDxV1RdMZtBcG3e_jDi4TlIx
>D
>>>M
>>>>Tz
>>>>>F
>>>>>>>M
>>>>>>>>tJguJhndpS2BnNhGoAWwBP-G2UCWlarucvId1iz_ea_AU-
>>>>>>>>U__8Gq6ZgF285KW8SRPHKr7NeWgE4dKG8o8PGMNJ3-
>>>>>>>>lAB4xdptdPAk1vfJe8AL_Tt6oCEoT0OAr4RrSIjzqtmugt8EHD-
>>>>>>>>jvxghKHjaWu1eGDkzOYtKpcV8WhZnz1wLItIZdChYT1xlXsFTU7-
>>>>>>>>GnJhN2jLvMMlZgkMxzQLejJ2aB1wogBTkBIipva21mNGaSFb_sSZhX9yc
>wi
>>T
>>>7
>>>>>U
>>>>>>M
>>>>>>>>UfQg5lyHCPZPEeP6/https%3A%2F%2Fxenomai.org%2Fpipermail%2Fx
>e
>>n
>>>o
>>>>>m
>>>>>>ai%
>>>>>>>>2F2022-April%2F047495.html
>>>>>>>>1. It is highly recommended to use a UART as kernel debug output.
>>>>>>>>2. enable CONFIG_XENO_OPT_WATCHDOG for xenomai, system will
>be
>>>>>able
>>>>>>>to
>>>>>>>>tell RT application "hangs" (infinite loop at high prio) apart
>>>>>>>>from real hangs/crashes.
>>>>>>>>
>>>>>>>>Regards
>>>>>>>>
>>>>>>>>Hongzhan Chen
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>We set up our system as like below sw.
>>>>>>>>>
>>>>>>>>>1. Xubuntu 18.04 LTS 32bit
>>>>>>>>>
>>>>>>>>>2. Linux kernel 4.1.18 32bit
>>>>>>>>>
>>>>>>>>>3. Xenomai 3.0.8 32bit
>>>>>>>>>
>>>>>>>>>4. Kernel config
>>>>>>>>>   We refer to the xenomai page as like below.
>>>>>>>>>
>>>>>>>>>https://secure-
>>>>>>>>web.cisco.com/1nAW3bSL64gGRUPlQWKtShagcypkiReyVX7nhG1T-J
>>>>>>>>>upEWaqU-3hnCSt542V_mEwX-
>>>>>>>>_8HsjCaWtSuQnJ3056Yq52DypR5psiqKgrOSq6pbk6xe-tw
>>>>>>>>>xYZhwwm0akkU4iVwFscbrRTWdk2Ul-
>>>>>>>>9fU2HilSTJ8rzI8X9LIfFg2foor5t9LawggXyjgq3
>>>>>>>>>QqwJktjRWEhqL8gFDP2PpsmxrTgVK6NzJdcBxzyOGo_jmjjiO009l74YL2
>>U
>>>5
>>>>K
>>>>>e
>>>>>>3
>>>>>>>A
>>>>>>>>7kc1AX7
>>>>>>>>>IV_t016CRGEK4QyAKRuSTqKzFm8t4flDV7eBT4m43w-o_SoFrKq-
>>>>>>>>AA7ZIKEYPEgpqq/http
>>>>>>>>>s%3A%2F%2Fsource.denx.de%2FXenomai%2Fxenomai%2F-
>>>>>>>>>/wikis/Configuring_For_X86_Based_Dual_Kernels#user-content-x86-
>>>>>>>>>processor-type
>>>>>>>>>
>>>>>>>>>Thanks.
>>>>>>>>>
>>>>>>>>>-----Original Message-----
>>>>>>>>>From: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>>>>>>Sent: Friday, August 26, 2022 2:40 PM
>>>>>>>>>To: 김동주(Dongjoo Kim) 책임연구원 두산로보틱스
>><dongjoo5.kim@doosan.com>;
>>>>>>>>>xenomai@xenomai.org
>>>>>>>>>Cc: 박영철(Youngchul Park) 수석연구원 두산로보틱스
>>>>><youngchul3.park@doosan.com>;
>>>>>>>>>박경훈(Kyunghoon Park) 수석연구원
>>>>>>>>두산로보틱스
>>>>>>>>><kyunghoon2.park@doosan.com>; 김세현(Sehyun Kim) 연구원
>>>>>>>>두산로보틱스
>>>>>>>>><sehyun2.kim@doosan.com>
>>>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>>>
>>>>>>>>>주의: 이 메일은 외부에서 발송 되었습니다. 링크 혹은 첨부파일
>>>열람
>>>>>시
>>>>>>>>주의하시기 바랍니다.
>>>>>>>>>
>>>>>>>>>CAUTION: This email is sent by an external account. Please take
>>>>>>>>>extra caution when clicking the link or opening the attachment.
>>>>>>>>>
>>>>>>>>>>-----Original Message-----
>>>>>>>>>>From: ???(Dongjoo Kim) ????? ?????? <dongjoo5.kim@doosan.com>
>>>>>>>>>>Sent: Friday, August 26, 2022 10:41 AM
>>>>>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>;
>>>>>>xenomai@xenomai.org
>>>>>>>>>>Cc: ???(Youngchul Park) ????? ??????
>>>>>>>>><youngchul3.park@doosan.com>; ???(Kyunghoon Park) ????? ??????
>>>>>>>>><kyunghoon2.park@doosan.com>; ???(Sehyun Kim) ??? ??????
>>>>>>>>><sehyun2.kim@doosan.com>; ???(Dongjoo Kim) ????? ??????
>>>>>>>>><dongjoo5.kim@doosan.com>
>>>>>>>>>>Subject: RE: What causes the latency of the rt_task_yield() API?
>>>>>>>>>>
>>>>>>>>>>Dear Xenomai.org, Chen, Hongzhan
>>>>>>>>>>
>>>>>>>>>>I'm dong joo.
>>>>>>>>>>
>>>>>>>>>>Thank you for your reply to us our questions.
>>>>>>>>>>
>>>>>>>>>>And, We have checked the value of TICK_NSEC int our system.
>>>>>>>>>>
>>>>>>>>>>#define TICK_NSEC ((NSEC_PER_SEC+HZ/2)/HZ)
>>>>>>>>>>#define NSEC_PER_SEC   1000000000L
>>>>>>>>>>HZ  250 ( Max 1000 )
>>>>>>>>>>
>>>>>>>>>>The value of TICK_NSEC is defined by linux kernel.
>>>>>>>>>>And, Both NSEC_PER_SEC and HZ calculate the value of TICK_NSEC.
>>>>>>>>>>
>>>>>>>>>>So, The current value of TICK_NSEC is 4ms based on 250 HZ.
>>>>>>>>>>And, If we change the value of HZ to 1000, The value of
>>>>>>>>>>TICK_NSEC may be
>>>>>>>>>1ms.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>We hope to process a task every 20us using rt_task_yield as
>>>>>>>>>>like Xenomai
>>>>>>>>>2.6.5.
>>>>>>>>>>
>>>>>>>>>>Is there any method to achieve 20us task delay using
>>>>>>>>>>rt_task_yield or another
>>>>>>>>>xenomai method ?
>>>>>>>>>>And, Is there any problem to reduce the delay more less than
>>>>>TICK_NSEC ?
>>>>>>>>>
>>>>>>>>>I just went through the implementation of rt_task_yield of
>>>>>>>>>Xeomai
>>>>>>>>>2.6.5 and found that it is totally different from Xenomai 3.0.8.
>>>>>>>>>If you want to yield about 20us for current RT thread ,you may
>>>>>>>>>try call clock_nanosleep .
>>>>>>>>>.
>>>>>>>>>Regards
>>>>>>>>>
>>>>>>>>>Hongzhan Chen
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>Really Thanks.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>This e-mail and any attachments herein may contain confidential
>>>>>>>>>or privileged information and is for the exclusive use of the
>>>>>>>>>intended
>>>>>>>>>recipient(s) named above. If you are not the intended
>>>>>>>>>recipient(s), you should not disseminate, distribute, retain,
>>>>>>>>>copy or otherwise use any information contained herein. If you
>>>>>>>>>have received this e-mail in error, please notify the sender
>>>>>>>>>immediately by replying to this message and
>>>>>>>>delete this e-mail and associated attachments.
>>>>>>>>>Our company does not guarantee this e-mail is secure or free
>>>>>>>>>from
>>>>>viruses.
>>>>>>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>>>>>>포함하고
>>>>>>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>>>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>>>>>>>용도로도 이를
>>>>>>>>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>>>>>>>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>>>>>>>>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>>>>>>>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>>>>>>>>
>>>>>>>>
>>>>>>>>This e-mail and any attachments herein may contain confidential
>>>>>>>>or privileged information and is for the exclusive use of the
>>>>>>>>intended
>>>>>>>>recipient(s) named above. If you are not the intended
>>>>>>>>recipient(s), you should not disseminate, distribute, retain,
>>>>>>>>copy or otherwise use any information contained herein. If you
>>>>>>>>have received this e-mail in error, please notify the sender
>>>>>>>>immediately by replying to this message and
>>>>>>>delete this e-mail and associated attachments.
>>>>>>>>Our company does not guarantee this e-mail is secure or free from
>>>>viruses.
>>>>>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>>>>>포함하고 있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>>>>>용도로도 이를
>>>>>>>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>>>>>>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>>>>>>>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>>>>>>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>>>>>>>
>>>>>>>
>>>>>>>This e-mail and any attachments herein may contain confidential or
>>>>>>privileged
>>>>>>>information and is for the exclusive use of the intended
>>>>>>>recipient(s) named above. If you are not the intended
>>>>>>>recipient(s), you should not disseminate, distribute, retain, copy
>>>>>>>or otherwise use any information contained herein. If you have
>>>>>>>received this e-mail in error, please notify the sender
>>>>>>>immediately
>>>>>>by
>>>>>>>replying to this message and delete this e-mail and associated
>>>attachments.
>>>>>>>Our company does not guarantee this e-mail is secure or free from
>>>viruses.
>>>>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>>>>포함하고
>>>>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>>>>>용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로
>>>>>>>발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지
>아니함을
>>>>>알려 드립니다. 잘못
>>>>>>수신하신
>>>>>>>경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기
>바랍니다. 협조에 감사 드립니다.
>>>>>
>>>>>
>>>>>This e-mail and any attachments herein may contain confidential or
>>>>privileged
>>>>>information and is for the exclusive use of the intended
>>>>>recipient(s) named above. If you are not the intended recipient(s),
>>>>>you should not disseminate, distribute, retain, copy or otherwise
>>>>>use any information contained herein. If you have received this
>>>>>e-mail in error, please notify the sender immediately
>>>>by
>>>>>replying to this message and delete this e-mail and associated
>attachments.
>>>>>Our company does not guarantee this e-mail is secure or free from
>viruses.
>>>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을
>>포함하고
>>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>>>용도로도 이를 이용할 수 없으며, 본 메일의 잘못된 취급으로
>>>>>발생하는 안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을
>>>알려 드립니다. 잘못
>>>>수신하신
>>>>>경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기
>>>>>바랍니다. 협조에 감사 드립니다.
>>>
>>>
>>>This e-mail and any attachments herein may contain confidential or
>>>privileged information and is for the exclusive use of the intended
>>>recipient(s) named above. If you are not the intended recipient(s),
>>>you should not disseminate, distribute, retain, copy or otherwise use
>>>any information contained herein. If you have received this e-mail in
>>>error, please notify the sender immediately by replying to this
>>>message and
>>delete this e-mail and associated attachments.
>>>Our company does not guarantee this e-mail is secure or free from viruses.
>>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로
>>>정당한 수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤
>용도로도 이를
>>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>>
>>
>>This e-mail and any attachments herein may contain confidential or
>>privileged information and is for the exclusive use of the intended
>>recipient(s) named above. If you are not the intended recipient(s), you
>>should not disseminate, distribute, retain, copy or otherwise use any
>>information contained herein. If you have received this e-mail in
>>error, please notify the sender immediately by replying to this message and
>delete this e-mail and associated attachments.
>>Our company does not guarantee this e-mail is secure or free from viruses.
>>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한
>>수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를
>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는
>>안전성 문제에 관하여 당사는 아무런 책임도 지지 아니함을 알려
>드립니다. 잘못 수신하신 경우에는 즉시 송신자에게 회신하여
>>알려주신 후 삭제하여 주시기 바랍니다. 협조에 감사 드립니다.
>
>
>This e-mail and any attachments herein may contain confidential or privileged
>information and is for the exclusive use of the intended recipient(s) named
>above. If you are not the intended recipient(s), you should not disseminate,
>distribute, retain, copy or otherwise use any information contained herein. If
>you have received this e-mail in error, please notify the sender immediately by
>replying to this message and delete this e-mail and associated attachments.
>Our company does not guarantee this e-mail is secure or free from viruses.
>이 메시지 및 첨부자료는 법률상 비밀로 보호되어야 할 내용을 포함하고
>있고 정당한 수신인에게만 전달할 목적으로 발송되었으므로 정당한
>수신인이 아니라면 내용의 공개, 배포, 보관은 물론 어떤 용도로도 이를
>이용할 수 없으며, 본 메일의 잘못된 취급으로 발생하는 안전성 문제에
>관하여 당사는 아무런 책임도 지지 아니함을 알려 드립니다. 잘못 수신하신
>경우에는 즉시 송신자에게 회신하여 알려주신 후 삭제하여 주시기
>바랍니다. 협조에 감사 드립니다.