When the linux process could recieve the message transport through XDDP？

When the linux process could recieve the message transport through XDDP？

[孙世龙]

Hi,
     As i am using XDDP to transport messages bettween the head domain and
linux domain(i mean there are two processes, one is rt process, the other
is linux process.),I wonder that when the linux process could recieve the
message？
     *Will ADOES wake up the related linux process at once when the head
domain write something to the XDDP node?* Or, the linux process has to wait
for the schedule of linux kernel, if the processor is busy, it may wait for
a long long time.

     Thank you for your attention.
     Looking forward to hearing from you.

Re: When the linux process could recieve the message transport through XDDP？

[steve freyder]

On 5/11/2020 9:16 PM, 孙世龙 via Xenomai wrote:
> Hi,
>       As i am using XDDP to transport messages bettween the head domain and
> linux domain(i mean there are two processes, one is rt process, the other
> is linux process.),I wonder that when the linux process could recieve the
> message？
>       *Will ADOES wake up the related linux process at once when the head
> domain write something to the XDDP node?* Or, the linux process has to wait
> for the schedule of linux kernel, if the processor is busy, it may wait for
> a long long time.
>
>       Thank you for your attention.
>       Looking forward to hearing from you.

The Linux process cannot wake up immediately, otherwise what would be 
the point of having an RT co-kernel if it didn't preempt the non-RT 
environment.


If the RT process wishes to give the non-RT process an opportunity to 
run in order to receive the just-sent message, it had better relinquish 
the CPU.  Inserting an rt_sleep() call (or equivalent) might be one 
(inelegant?) option, but certainly nothing in iPipe or anything at that 
layer is going to magically solve that problem for you.


If you're going to build code that makes a NRT process a subordinate of 
an RT process, you're going to have to employ some non-standard logic 
and get creative about how you deal with the inverted priority 
relationship that implicitly exists between the RT/NRT schedulers 
involved in that scenario.  XDDP is a bidirectional data relay, not a 
scheduler.


Regards,

Steve

Re: When the linux process could recieve the message transport through XDDP？

[孙世龙]

Hi,Steve:
     Thank you for the clarification.

    >>Will ADOES wake up the related linux process at once when the head
    >>domain write something to the XDDP node?* Or, the linux process
    >>has to wait for the schedule of linux kernel, if the processor is
    >>busy, it may wait for a long long time.
    >The Linux process cannot wake up immediately, otherwise what would
    >be the point of having an RT co-kernel if it didn't preempt the
    >non-RT environment.
     Yea，I can't agree  more.
     Imagine this  scenario, your processor have 4 cores and you only have
one
     RT process which has single thread.So, there are 3 cores could be used
     for the linux processes at least. What i am interested in is that* if *
*     the linux process wait to receive message through XDDP has to compete*
*     for the cpu resources** with so many other linux processes .*

     >If you're going to build code that makes a NRT process a subordinate
     >of an RT process, you're going to have to employ some non-standard
    >logic and get creative about how you deal with the inverted priority
    >relationship that implicitly exists between the RT/NRT schedulers
    >involved in that scenario.

    What do you mean by " employ  some non-standard logic"？Could you make
me more clearlly?

     Thank you for your attention.
     Look forward to hearing from you.

steve freyder <steve@freyder.net> 于2020年5月12日周二 上午11:43写道：

> On 5/11/2020 9:16 PM, 孙世龙 via Xenomai wrote:
>
> Hi,
>      As i am using XDDP to transport messages bettween the head domain and
> linux domain(i mean there are two processes, one is rt process, the other
> is linux process.),I wonder that when the linux process could recieve the
> message？
>      *Will ADOES wake up the related linux process at once when the head
> domain write something to the XDDP node?* Or, the linux process has to wait
> for the schedule of linux kernel, if the processor is busy, it may wait for
> a long long time.
>
>      Thank you for your attention.
>      Looking forward to hearing from you.
>
> The Linux process cannot wake up immediately, otherwise what would be the
> point of having an RT co-kernel if it didn't preempt the non-RT environment.
>
>
> If the RT process wishes to give the non-RT process an opportunity to run
> in order to receive the just-sent message, it had better relinquish the
> CPU.  Inserting an rt_sleep() call (or equivalent) might be one
> (inelegant?) option, but certainly nothing in iPipe or anything at that
> layer is going to magically solve that problem for you.
>
>
> If you're going to build code that makes a NRT process a subordinate of an
> RT process, you're going to have to employ some non-standard logic and get
> creative about how you deal with the inverted priority relationship that
> implicitly exists between the RT/NRT schedulers involved in that scenario.
> XDDP is a bidirectional data relay, not a scheduler.
>
>
> Regards,
>
> Steve
>
>
>

Re: When the linux process could recieve the message transport through XDDP？

[steve freyder]

On 5/12/2020 1:37 AM, 孙世龙 wrote:
> Hi,Steve:
>      Thank you for the clarification.
>
>     >>Will ADOES wake up the related linux process at once when the head
>     >>domain write something to the XDDP node?* Or, the linux process
>     >>has to wait for the schedule of linux kernel, if the processor is
>     >>busy, it may wait for a long long time.
>     >The Linux process cannot wake up immediately, otherwise what would
>     >be the point of having an RT co-kernel if it didn't preempt the
>     >non-RT environment.
>      Yea，I can't agree  more.
>      Imagine this scenario, your processor have 4 cores and you only 
> have one
>      RT process which has single thread.So, there are 3 cores could be 
> used
>      for the linux processes at least. What i am interested in is 
> that*if *
> *     the linux process wait to receive message through XDDP has to 
> compete*
> *     for the cpu resources** with so many other linux processes .*
>      >If you're going to build code that makes a NRT process a subordinate
>      >of an RT process, you're going to have to employ some non-standard
>     >logic and get creative about how you deal with the inverted priority
>     >relationship that implicitly exists between the RT/NRT schedulers
>     >involved in that scenario.
>     What do you mean by " employ  some non-standard logic"？Could you 
> make me more clearlly?
>
>      Thank you for your attention.
>      Look forward to hearing from you.
>
> steve freyder <steve@freyder.net <mailto:steve@freyder.net>> 
> 于2020年5月12日周二 上午11:43写道：
>
>     On 5/11/2020 9:16 PM, 孙世龙 via Xenomai wrote:
>>     Hi,
>>           As i am using XDDP to transport messages bettween the head domain and
>>     linux domain(i mean there are two processes, one is rt process, the other
>>     is linux process.),I wonder that when the linux process could recieve the
>>     message？
>>           *Will ADOES wake up the related linux process at once when the head
>>     domain write something to the XDDP node?* Or, the linux process has to wait
>>     for the schedule of linux kernel, if the processor is busy, it may wait for
>>     a long long time.
>>
>>           Thank you for your attention.
>>           Looking forward to hearing from you.
>
>     The Linux process cannot wake up immediately, otherwise what would
>     be the point of having an RT co-kernel if it didn't preempt the
>     non-RT environment.
>
>
>     If the RT process wishes to give the non-RT process an opportunity
>     to run in order to receive the just-sent message, it had better
>     relinquish the CPU.  Inserting an rt_sleep() call (or equivalent)
>     might be one (inelegant?) option, but certainly nothing in iPipe
>     or anything at that layer is going to magically solve that problem
>     for you.
>
>
>     If you're going to build code that makes a NRT process a
>     subordinate of an RT process, you're going to have to employ some
>     non-standard logic and get creative about how you deal with the
>     inverted priority relationship that implicitly exists between the
>     RT/NRT schedulers involved in that scenario.  XDDP is a
>     bidirectional data relay, not a scheduler.
>
>
>     Regards,
>
>     Steve
>
>
You're right, and I shouldn't have ignored the scenario that you pointed 
out where there are multiple CPUs available.  Certainly if there is more 
than one CPU, then it's possible for the Linux process on the NRT side 
of the XDDP socket to wake up immediately when the RT side sends data on 
the socket assuming that the NRT process is waiting for read completion 
and that it's the highest priority process on the Linux side.  To the 
extent that you can ensure those conditions are met, you'll be able to 
ensure the kind of performance you're looking for.