[Xenomai-help] RT Task RPC over a POSIX/Native Queue

[Xenomai-help] RT Task RPC over a POSIX/Native Queue

[Guvenc Gulce]

Hi 
As far as I know an Xenomai RT Task can not call Linux API functions without leaving the Xenomai domain.

I was thinking about a generic library/framework which would allow an Xenomai RT Task call a Linux API 
function which would be then marshalled over a Posix/Native Queue to another Xenomai RT Task which then 
would do the dirty job of calling Linux functions. The responses and function return values from linux functions 
can be marshalled back to the original Xenomai RT-Task caller again over another Posix/Native Queue. In such 
a scenario the original caller RT Task would stay always in Xenomai domain. 

I would like to hear whether such an approach sounds feasible/reasonable given the fact that currently 
Xenomai RT Tasks can not call Linux functions without leaving the Xenomai domain. Such a library/framework 
would be a solution to overcome that constraint. I would be glad to hear some opinions about this.

Thanks & Regards,

Guvenc  


      

Re: [Xenomai-help] RT Task RPC over a POSIX/Native Queue

[Gilles Chanteperdrix]

Guvenc Gulce wrote:
> Hi As far as I know an Xenomai RT Task can not call Linux API
> functions without leaving the Xenomai domain.
> 
> I was thinking about a generic library/framework which would allow an
> Xenomai RT Task call a Linux API function which would be then
> marshalled over a Posix/Native Queue to another Xenomai RT Task which
> then would do the dirty job of calling Linux functions. The responses
> and function return values from linux functions can be marshalled
> back to the original Xenomai RT-Task caller again over another
> Posix/Native Queue. In such a scenario the original caller RT Task
> would stay always in Xenomai domain.
> 
> I would like to hear whether such an approach sounds
> feasible/reasonable given the fact that currently Xenomai RT Tasks
> can not call Linux functions without leaving the Xenomai domain. Such
> a library/framework would be a solution to overcome that constraint.
> I would be glad to hear some opinions about this.

Leaving Xenomai domain is not bad per se. The reason why it is bad is
that when re-entering Linux domain, you may have to wait an unbounded
time for Linux to let your task run.

With your approach, the first RT task would not leave the Xenomai
domain, but it would wait for the second RT task to complete. And the
second RT task would risk to wait for the same unbounded time.

So, in short, you gain nothing.

-- 
                                          Gilles

Re: [Xenomai-help] RT Task RPC over a POSIX/Native Queue

[Alphan Ulusoy]

[-- Attachment #1: Type: text/plain, Size: 1609 bytes --]

You can always use the Xenomai's _wonderful_ pipe functionality (and  
other task communication services as well) to communicate data back  
and forth between RT (Xenomai user -or- kernel space tasks) and non-RT  
(dedicated linux executables) tasks. This also ensures that your RT  
and non-RT domains are clearly separated by design, which is a good  
thing IMHO.


-- 
alphan




On 8 Sep, 2009, at 8:10 PM, Guvenc Gulce wrote:

> Hi
> As far as I know an Xenomai RT Task can not call Linux API functions  
> without leaving the Xenomai domain.
>
> I was thinking about a generic library/framework which would allow  
> an Xenomai RT Task call a Linux API
> function which would be then marshalled over a Posix/Native Queue to  
> another Xenomai RT Task which then
> would do the dirty job of calling Linux functions. The responses and  
> function return values from linux functions
> can be marshalled back to the original Xenomai RT-Task caller again  
> over another Posix/Native Queue. In such
> a scenario the original caller RT Task would stay always in Xenomai  
> domain.
>
> I would like to hear whether such an approach sounds feasible/ 
> reasonable given the fact that currently
> Xenomai RT Tasks can not call Linux functions without leaving the  
> Xenomai domain. Such a library/framework
> would be a solution to overcome that constraint. I would be glad to  
> hear some opinions about this.
>
> Thanks & Regards,
>
> Guvenc
>
>
>
>
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
>


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2433 bytes --]

Re: [Xenomai-help] RT Task RPC over a POSIX/Native Queue

[Gilles Chanteperdrix]

Alphan Ulusoy wrote:
> You can always use the Xenomai's _wonderful_ pipe functionality (and  
> other task communication services as well) to communicate data back  
> and forth between RT (Xenomai user -or- kernel space tasks) and non-RT  
> (dedicated linux executables) tasks. This also ensures that your RT  
> and non-RT domains are clearly separated by design, which is a good  
> thing IMHO.

Waiting for the non real-time task to post an answer through rt-pipes is
as dangerous for the real-time task determinism as with message queues
of any kind.

Besides, a task with low priority which oscillates between first and
secondary modes does not threaten a primary mode only task determinism
any more than a non real-time tasks. However, it can communicates with
the primary mode only task with a lot more IPCs and synchronization
mechanisms.

And there is no difference in design between an application separated
between real-time and non real-time tasks on the one hand, and an
application separated between real-time and oscillating tasks on the
other hand. The real gain in design happens when you can split driver
code from application code.

-- 
					    Gilles.

Re: [Xenomai-help] RT Task RPC over a POSIX/Native Queue

[Alphan Ulusoy]

[-- Attachment #1: Type: text/plain, Size: 1865 bytes --]

My post was probably not clear enough: I was thinking about something  
more like a source-sink scheme: an RT task generating some data to be  
processed (to be saved, printed, displayed, etc.) by the non-RT task  
or a non-RT task streaming chunks of data to the RT-task (to be  
decoded, etc.); not a non-RT => RT feedback mechanism.

> Waiting for the non real-time task to post an answer through rt- 
> pipes is
> as dangerous for the real-time task determinism as with message queues
> of any kind.

For other cases, your above comment is totally accurate of course.

-- 
alphan




On 8 Sep, 2009, at 10:24 PM, Gilles Chanteperdrix wrote:

> Alphan Ulusoy wrote:
>> You can always use the Xenomai's _wonderful_ pipe functionality (and
>> other task communication services as well) to communicate data back
>> and forth between RT (Xenomai user -or- kernel space tasks) and non- 
>> RT
>> (dedicated linux executables) tasks. This also ensures that your RT
>> and non-RT domains are clearly separated by design, which is a good
>> thing IMHO.
>
> Waiting for the non real-time task to post an answer through rt- 
> pipes is
> as dangerous for the real-time task determinism as with message queues
> of any kind.
>
> Besides, a task with low priority which oscillates between first and
> secondary modes does not threaten a primary mode only task determinism
> any more than a non real-time tasks. However, it can communicates with
> the primary mode only task with a lot more IPCs and synchronization
> mechanisms.
>
> And there is no difference in design between an application separated
> between real-time and non real-time tasks on the one hand, and an
> application separated between real-time and oscillating tasks on the
> other hand. The real gain in design happens when you can split driver
> code from application code.
>
> -- 
> 					    Gilles.
>


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2433 bytes --]

Re: [Xenomai-help] RT Task RPC over a POSIX/Native Queue

[Guvenc Gulce]

Guvenc Gulce wrote:

>>> Leaving Xenomai domain is not bad per se. The reason why it is bad is
>> 
>>> that when re-entering Linux domain, you may have to wait an unbounded
>>> time for Linux to let your task run.
>> 
>> Exactly and that would disturb the real-timeliness of the rt task.
>> 
>>> With your approach, the first RT task would not leave the Xenomai
>>> domain, but it would wait for the second RT task to complete. And the
>>> second RT task would risk to wait for the same unbounded time.
>> 
>> Why should the first RT Task wait for the second RT Task when 
>> the second RT Task has lower priority than the first one ? If Xenomai 
>> scheduler works as expected then the first rt task should be 
>> able to continue to run after writing into Posix Queue (marshalled Linux 
>> call) and collect the results of the called linux function when 
>> the second rt task gets them and marshalls them back to a second 
>> feedback Queue which can be read by the first RT Task when 
>> it is appropriate for it. (Feedback Queue needs to be polled by the 
>> first RT Task as there is no async communication possibility in 
>> Userspace Realtime Environment) 

>> 
>> The main advantage here is that the original RT Task never loses his 
>> determinism as it might be doing some other jobs other than waiting 
>> for the answers from the called linux functions.  
>> 
>>> So, in short, you gain nothing.
>> I think the gain is that the original rt task stays deterministic and is still able 
>> to call the linux functions and can continue to do his job which needs 
>> determinism and may poll the feedback Queue some time later and 
>> get the results of the called linux function. 
>> Such a thing is impossible to do with the current Xenomai API, 

>Yes, you could do that, though, I do not see any real-world application
>where this would make sense. I mean, if you call a function you
>generally want to get the result immediately. What application do you
>have in mind?

Opps.. I didnt realize that I was replying to you and not to the list.. 

A typical application would be for example to offer a rt task the 
possibility of network communication without disturbing its determinism. 
If you send a data over the network, you dont necessarily expect 
the reply immediately or write to the file system again without 
disturbing the determinism. 

Regards,

Guvenc


      

Re: [Xenomai-help] RT Task RPC over a POSIX/Native Queue

[Gilles Chanteperdrix]

Guvenc Gulce wrote:
> Guvenc Gulce wrote:
> 
>>>> Leaving Xenomai domain is not bad per se. The reason why it is bad is
>>>> that when re-entering Linux domain, you may have to wait an unbounded
>>>> time for Linux to let your task run.
>>> Exactly and that would disturb the real-timeliness of the rt task.
>>>
>>>> With your approach, the first RT task would not leave the Xenomai
>>>> domain, but it would wait for the second RT task to complete. And the
>>>> second RT task would risk to wait for the same unbounded time.
>>> Why should the first RT Task wait for the second RT Task when 
>>> the second RT Task has lower priority than the first one ? If Xenomai 
>>> scheduler works as expected then the first rt task should be 
>>> able to continue to run after writing into Posix Queue (marshalled Linux 
>>> call) and collect the results of the called linux function when 
>>> the second rt task gets them and marshalls them back to a second 
>>> feedback Queue which can be read by the first RT Task when 
>>> it is appropriate for it. (Feedback Queue needs to be polled by the 
>>> first RT Task as there is no async communication possibility in 
>>> Userspace Realtime Environment) 
> 
>>> The main advantage here is that the original RT Task never loses his 
>>> determinism as it might be doing some other jobs other than waiting 
>>> for the answers from the called linux functions.  
>>>
>>>> So, in short, you gain nothing.
>>> I think the gain is that the original rt task stays deterministic and is still able 
>>> to call the linux functions and can continue to do his job which needs 
>>> determinism and may poll the feedback Queue some time later and 
>>> get the results of the called linux function. 
>>> Such a thing is impossible to do with the current Xenomai API, 
> 
>> Yes, you could do that, though, I do not see any real-world application
>> where this would make sense. I mean, if you call a function you
>> generally want to get the result immediately. What application do you
>> have in mind?
> 
> Opps.. I didnt realize that I was replying to you and not to the list.. 
> 
> A typical application would be for example to offer a rt task the 
> possibility of network communication without disturbing its determinism. 
> If you send a data over the network, you dont necessarily expect 
> the reply immediately or write to the file system again without 
> disturbing the determinism. 

We have rtnet, a deterministic networking stack. For writing to the
filesystem, we have rtdk.

-- 
					    Gilles.

Re: [Xenomai-help] RT Task RPC over a POSIX/Native Queue

[Guvenc Gulce]

rt_net is nice but then all network participants have to use rt_net otherwise 
the realtime communication is not guaranteed on the wire.. in some cases 
the real-timeliness on the wire may not be needed but the determinism 
of the rt-task may still be an issue..

I think it is a great flexibility to give an rt task the chance to communicate 
with non rt_net clients and servers in the network without worrying about 
losing its determinism. 

Regards,

Guvenc



----- Original Message ----
From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: Guvenc Gulce <gulceg@domain.hid>
Cc: xenomai@xenomai.org
Sent: Wednesday, September 9, 2009 12:44:23 AM
Subject: Re: [Xenomai-help] RT Task RPC over a POSIX/Native Queue

Guvenc Gulce wrote:
> Guvenc Gulce wrote:
> 
>>>> Leaving Xenomai domain is not bad per se. The reason why it is bad is
>>>> that when re-entering Linux domain, you may have to wait an unbounded
>>>> time for Linux to let your task run.
>>> Exactly and that would disturb the real-timeliness of the rt task.
>>>
>>>> With your approach, the first RT task would not leave the Xenomai
>>>> domain, but it would wait for the second RT task to complete. And the
>>>> second RT task would risk to wait for the same unbounded time.
>>> Why should the first RT Task wait for the second RT Task when 
>>> the second RT Task has lower priority than the first one ? If Xenomai 
>>> scheduler works as expected then the first rt task should be 
>>> able to continue to run after writing into Posix Queue (marshalled Linux 
>>> call) and collect the results of the called linux function when 
>>> the second rt task gets them and marshalls them back to a second 
>>> feedback Queue which can be read by the first RT Task when 
>>> it is appropriate for it. (Feedback Queue needs to be polled by the 
>>> first RT Task as there is no async communication possibility in 
>>> Userspace Realtime Environment) 
> 
>>> The main advantage here is that the original RT Task never loses his 
>>> determinism as it might be doing some other jobs other than waiting 
>>> for the answers from the called linux functions.  
>>>
>>>> So, in short, you gain nothing.
>>> I think the gain is that the original rt task stays deterministic and is still able 
>>> to call the linux functions and can continue to do his job which needs 
>>> determinism and may poll the feedback Queue some time later and 
>>> get the results of the called linux function. 
>>> Such a thing is impossible to do with the current Xenomai API, 
> 
>> Yes, you could do that, though, I do not see any real-world application
>> where this would make sense. I mean, if you call a function you
>> generally want to get the result immediately. What application do you
>> have in mind?
> 
> Opps.. I didnt realize that I was replying to you and not to the list.. 
> 
> A typical application would be for example to offer a rt task the 
> possibility of network communication without disturbing its determinism. 
> If you send a data over the network, you dont necessarily expect 
> the reply immediately or write to the file system again without 
> disturbing the determinism. 

We have rtnet, a deterministic networking stack. For writing to the
filesystem, we have rtdk.

-- 
                        Gilles.



      

Re: [Xenomai-help] RT Task RPC over a POSIX/Native Queue

[Stuart O Anderson]

I am working with a similar problem at the moment.  I have a realtime
task that uses rt_net to do UDP communication with embedded systems on
several physical networks.  I also need to collect data used by that
realtime task from a third party server streaming data using a TCP
based protocol.  My approach has been to run one realtime thread and
one user-space thread in the same process.  The user space thread
talks to the third party server and posts data to memory, while the
realtime task reads from this memory and communicates with the
embedded systems.

When I run the realtime thread alone, the 1 KHz timing is quite
stable.  Currently, however, when I run the userspace thread as well
and have it make networking calls, I lose timing precision in the
realtime thread.  I'm still working on understanding why.

Stuart

On Tue, Sep 8, 2009 at 6:53 PM, Guvenc Gulce<gulceg@domain.hid> wrote:
> rt_net is nice but then all network participants have to use rt_net otherwise
> the realtime communication is not guaranteed on the wire.. in some cases
> the real-timeliness on the wire may not be needed but the determinism
> of the rt-task may still be an issue..
>
> I think it is a great flexibility to give an rt task the chance to communicate
> with non rt_net clients and servers in the network without worrying about
> losing its determinism.
>
> Regards,
>
> Guvenc
>
>
>
> ----- Original Message ----
> From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> To: Guvenc Gulce <gulceg@domain.hid>
> Cc: xenomai@xenomai.org
> Sent: Wednesday, September 9, 2009 12:44:23 AM
> Subject: Re: [Xenomai-help] RT Task RPC over a POSIX/Native Queue
>
> Guvenc Gulce wrote:
>> Guvenc Gulce wrote:
>>
>>>>> Leaving Xenomai domain is not bad per se. The reason why it is bad is
>>>>> that when re-entering Linux domain, you may have to wait an unbounded
>>>>> time for Linux to let your task run.
>>>> Exactly and that would disturb the real-timeliness of the rt task.
>>>>
>>>>> With your approach, the first RT task would not leave the Xenomai
>>>>> domain, but it would wait for the second RT task to complete. And the
>>>>> second RT task would risk to wait for the same unbounded time.
>>>> Why should the first RT Task wait for the second RT Task when
>>>> the second RT Task has lower priority than the first one ? If Xenomai
>>>> scheduler works as expected then the first rt task should be
>>>> able to continue to run after writing into Posix Queue (marshalled Linux
>>>> call) and collect the results of the called linux function when
>>>> the second rt task gets them and marshalls them back to a second
>>>> feedback Queue which can be read by the first RT Task when
>>>> it is appropriate for it. (Feedback Queue needs to be polled by the
>>>> first RT Task as there is no async communication possibility in
>>>> Userspace Realtime Environment)
>>
>>>> The main advantage here is that the original RT Task never loses his
>>>> determinism as it might be doing some other jobs other than waiting
>>>> for the answers from the called linux functions.
>>>>
>>>>> So, in short, you gain nothing.
>>>> I think the gain is that the original rt task stays deterministic and is still able
>>>> to call the linux functions and can continue to do his job which needs
>>>> determinism and may poll the feedback Queue some time later and
>>>> get the results of the called linux function.
>>>> Such a thing is impossible to do with the current Xenomai API,
>>
>>> Yes, you could do that, though, I do not see any real-world application
>>> where this would make sense. I mean, if you call a function you
>>> generally want to get the result immediately. What application do you
>>> have in mind?
>>
>> Opps.. I didnt realize that I was replying to you and not to the list..
>>
>> A typical application would be for example to offer a rt task the
>> possibility of network communication without disturbing its determinism.
>> If you send a data over the network, you dont necessarily expect
>> the reply immediately or write to the file system again without
>> disturbing the determinism.
>
> We have rtnet, a deterministic networking stack. For writing to the
> filesystem, we have rtdk.
>
> --
>                        Gilles.
>
>
>
>
>
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
>

Re: [Xenomai-help] RT Task RPC over a POSIX/Native Queue

[Gilles Chanteperdrix]

Guvenc Gulce wrote:
> rt_net is nice but then all network participants have to use rt_net otherwise 
> the realtime communication is not guaranteed on the wire.. in some cases 
> the real-timeliness on the wire may not be needed but the determinism 
> of the rt-task may still be an issue..
> 
> I think it is a great flexibility to give an rt task the chance to communicate 
> with non rt_net clients and servers in the network without worrying about 
> losing its determinism. 

You can do that with rtnet.

-- 
                                          Gilles

Re: [Xenomai-help] RT Task RPC over a POSIX/Native Queue

[Philippe Gerum]

On Tue, 2009-09-08 at 19:02 -0400, Stuart O Anderson wrote:
> I am working with a similar problem at the moment.  I have a realtime
> task that uses rt_net to do UDP communication with embedded systems on
> several physical networks.  I also need to collect data used by that
> realtime task from a third party server streaming data using a TCP
> based protocol.  My approach has been to run one realtime thread and
> one user-space thread in the same process.  The user space thread
> talks to the third party server and posts data to memory, while the
> realtime task reads from this memory and communicates with the
> embedded systems.
> 
> When I run the realtime thread alone, the 1 KHz timing is quite
> stable.  Currently, however, when I run the userspace thread as well
> and have it make networking calls, I lose timing precision in the
> realtime thread.  I'm still working on understanding why.

Any synchronization between the RT and NRT threads reading/writing to
the shared memory at work? a semaphore to get clean reads for instance,
or anything alike, that would actually propagate the NRT latencies to
the RT thread?

You may want to have a look at /proc/xenomai/stat for your RT thread as
well. Specifically the MSW counter: it's value should not increase over
time if that thread is expected to always work in primary (rt) mode.

> 
> Stuart
> 
> On Tue, Sep 8, 2009 at 6:53 PM, Guvenc Gulce<gulceg@domain.hid> wrote:
> > rt_net is nice but then all network participants have to use rt_net otherwise
> > the realtime communication is not guaranteed on the wire.. in some cases
> > the real-timeliness on the wire may not be needed but the determinism
> > of the rt-task may still be an issue..
> >
> > I think it is a great flexibility to give an rt task the chance to communicate
> > with non rt_net clients and servers in the network without worrying about
> > losing its determinism.
> >
> > Regards,
> >
> > Guvenc
> >
> >
> >
> > ----- Original Message ----
> > From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> > To: Guvenc Gulce <gulceg@domain.hid>
> > Cc: xenomai@xenomai.org
> > Sent: Wednesday, September 9, 2009 12:44:23 AM
> > Subject: Re: [Xenomai-help] RT Task RPC over a POSIX/Native Queue
> >
> > Guvenc Gulce wrote:
> >> Guvenc Gulce wrote:
> >>
> >>>>> Leaving Xenomai domain is not bad per se. The reason why it is bad is
> >>>>> that when re-entering Linux domain, you may have to wait an unbounded
> >>>>> time for Linux to let your task run.
> >>>> Exactly and that would disturb the real-timeliness of the rt task.
> >>>>
> >>>>> With your approach, the first RT task would not leave the Xenomai
> >>>>> domain, but it would wait for the second RT task to complete. And the
> >>>>> second RT task would risk to wait for the same unbounded time.
> >>>> Why should the first RT Task wait for the second RT Task when
> >>>> the second RT Task has lower priority than the first one ? If Xenomai
> >>>> scheduler works as expected then the first rt task should be
> >>>> able to continue to run after writing into Posix Queue (marshalled Linux
> >>>> call) and collect the results of the called linux function when
> >>>> the second rt task gets them and marshalls them back to a second
> >>>> feedback Queue which can be read by the first RT Task when
> >>>> it is appropriate for it. (Feedback Queue needs to be polled by the
> >>>> first RT Task as there is no async communication possibility in
> >>>> Userspace Realtime Environment)
> >>
> >>>> The main advantage here is that the original RT Task never loses his
> >>>> determinism as it might be doing some other jobs other than waiting
> >>>> for the answers from the called linux functions.
> >>>>
> >>>>> So, in short, you gain nothing.
> >>>> I think the gain is that the original rt task stays deterministic and is still able
> >>>> to call the linux functions and can continue to do his job which needs
> >>>> determinism and may poll the feedback Queue some time later and
> >>>> get the results of the called linux function.
> >>>> Such a thing is impossible to do with the current Xenomai API,
> >>
> >>> Yes, you could do that, though, I do not see any real-world application
> >>> where this would make sense. I mean, if you call a function you
> >>> generally want to get the result immediately. What application do you
> >>> have in mind?
> >>
> >> Opps.. I didnt realize that I was replying to you and not to the list..
> >>
> >> A typical application would be for example to offer a rt task the
> >> possibility of network communication without disturbing its determinism.
> >> If you send a data over the network, you dont necessarily expect
> >> the reply immediately or write to the file system again without
> >> disturbing the determinism.
> >
> > We have rtnet, a deterministic networking stack. For writing to the
> > filesystem, we have rtdk.
> >
> > --
> >                        Gilles.
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Xenomai-help mailing list
> > Xenomai-help@domain.hid
> > https://mail.gna.org/listinfo/xenomai-help
> >
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-help] RT Task RPC over a POSIX/Native Queue

[Guvenc Gulce]

How can I do that with rt_net ? Any pointers, any examples ? rt_net documentation 
talks about the hard real-timeliness on the wire.. can I separate rt_net and rt_mac ? 
I don't need real-timeliness on the wire why should I pollute my Network 
with the MAC level ethernet packets sent by rt_mac to guarantee the 
real-timeliness which I don't need ?

Guvenc

 



----- Original Message ----
From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: Guvenc Gulce <gulceg@domain.hid>
Cc: xenomai@xenomai.org
Sent: Wednesday, September 9, 2009 10:24:08 AM
Subject: Re: [Xenomai-help] RT Task RPC over a POSIX/Native Queue

Guvenc Gulce wrote:
> rt_net is nice but then all network participants have to use rt_net otherwise 
> the realtime communication is not guaranteed on the wire.. in some cases 
> the real-timeliness on the wire may not be needed but the determinism 
> of the rt-task may still be an issue..
> 
> I think it is a great flexibility to give an rt task the chance to communicate 
> with non rt_net clients and servers in the network without worrying about 
> losing its determinism. 

You can do that with rtnet.

-- 
                                          Gilles


      

Re: [Xenomai-help] RT Task RPC over a POSIX/Native Queue

[Gilles Chanteperdrix]

Guvenc Gulce wrote:
> How can I do that with rt_net ? Any pointers, any examples ? rt_net documentation 
> talks about the hard real-timeliness on the wire.. can I separate rt_net and rt_mac ? 
> I don't need real-timeliness on the wire why should I pollute my Network 
> with the MAC level ethernet packets sent by rt_mac to guarantee the 
> real-timeliness which I don't need ?

Use the nomac module. But it is true that it is not really what rtnet
was designed to do, which is probably why it is not documented.

-- 
                                          Gilles

Re: [Xenomai-help] RT Task RPC over a POSIX/Native Queue

[Jan Kiszka]

Guvenc Gulce wrote:
> rt_net is nice but then all network participants have to use rt_net otherwise 
> the realtime communication is not guaranteed on the wire.. in some cases 
> the real-timeliness on the wire may not be needed but the determinism 
> of the rt-task may still be an issue..
> 
> I think it is a great flexibility to give an rt task the chance to communicate 
> with non rt_net clients and servers in the network without worrying about 
> losing its determinism. 

To achieve this, you just need to set up a low-prio Xenomai server task
that accepts to-be-transmitted data from the RT task sends it out,
collects replies and dispatches them back to the sender. You may use
queues or shared memory as IPC mechanisms for the RT<->proxy
communication. They just have to be Xenomai provided. The effect will be
that the proxy is switching back and forth between primary (Xenomai) and
secondary (Linux) mode, but your RT task will stay in primary mode.

As you do not care about determinism of the network communication, you
also do not need RTnet. It would only introduce the risk that non-RT
network participant overload your box. And this load would show up in
the RT domain because RTnet would have to handle it.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-help] RT Task RPC over a POSIX/Native Queue

[Guvenc Gulce]

Gilles Thanks.. I will look into the nomac possibility in rtnet..

And Jan.. your comments here brings me back to my original 
post in this topic where I said:


>I was thinking about a generic library/framework which would allow an Xenomai 
>RT Task call a Linux API 
>function which would be then marshalled over a Posix/Native Queue to another 
>Xenomai RT Task which then 
>would do the dirty job of calling Linux functions.

and when we are at it why not to make a generic thing from 
this low prio proxy RT Task <-> RT Task communicate with each other with IPC 
and low prio RT Task does the dirty job of calling Linux API idea.. such a 
thing may be needed for other Linux APIs and not only for the network part..

I will try to develop this idea and prepare some test code maybe the 
community is also interested to have it in Xenomai tree.. more 
comments are also welcome..

Thanks & Regards

Guvenc 




----- Original Message ----
From: Jan Kiszka <jan.kiszka@domain.hid>
To: Guvenc Gulce <gulceg@domain.hid>
Cc: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>; xenomai@xenomai.org
Sent: Wednesday, September 9, 2009 12:12:29 PM
Subject: Re: RT Task RPC over a POSIX/Native Queue

Guvenc Gulce wrote:
> rt_net is nice but then all network participants have to use rt_net otherwise 
> the realtime communication is not guaranteed on the wire.. in some cases 
> the real-timeliness on the wire may not be needed but the determinism 
> of the rt-task may still be an issue..
> 
> I think it is a great flexibility to give an rt task the chance to communicate 
> with non rt_net clients and servers in the network without worrying about 
> losing its determinism. 

To achieve this, you just need to set up a low-prio Xenomai server task
that accepts to-be-transmitted data from the RT task sends it out,
collects replies and dispatches them back to the sender. You may use
queues or shared memory as IPC mechanisms for the RT<->proxy
communication. They just have to be Xenomai provided. The effect will be
that the proxy is switching back and forth between primary (Xenomai) and
secondary (Linux) mode, but your RT task will stay in primary mode.

As you do not care about determinism of the network communication, you
also do not need RTnet. It would only introduce the risk that non-RT
network participant overload your box. And this load would show up in
the RT domain because RTnet would have to handle it.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux



      

Re: [Xenomai-help] RT Task RPC over a POSIX/Native Queue

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> As you do not care about determinism of the network communication, you
> also do not need RTnet. It would only introduce the risk that non-RT
> network participant overload your box. And this load would show up in
> the RT domain because RTnet would have to handle it.

You can solve that by limiting the non real-time traffic to a maximum
rate, and always keep some bandwidth for the real-time traffic. This is
a bit more complicated than nomac, but not that much. But of course if
you do not need packets to be sent ASAP, I agree that rtnet is overkill.

-- 
                                          Gilles

Re: [Xenomai-help] RT Task RPC over a POSIX/Native Queue

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> As you do not care about determinism of the network communication, you
>> also do not need RTnet. It would only introduce the risk that non-RT
>> network participant overload your box. And this load would show up in
>> the RT domain because RTnet would have to handle it.
> 
> You can solve that by limiting the non real-time traffic to a maximum
> rate, and always keep some bandwidth for the real-time traffic. This is
> a bit more complicated than nomac, but not that much. But of course if
> you do not need packets to be sent ASAP, I agree that rtnet is overkill.

Right. But the problem, err, challenge is that this rate limiting has to
be installed either into the switch/router that your RT box is attached
to or into all nodes that may talk to it.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-help] RT Task RPC over a POSIX/Native Queue

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> As you do not care about determinism of the network communication, you
>>> also do not need RTnet. It would only introduce the risk that non-RT
>>> network participant overload your box. And this load would show up in
>>> the RT domain because RTnet would have to handle it.
>> You can solve that by limiting the non real-time traffic to a maximum
>> rate, and always keep some bandwidth for the real-time traffic. This is
>> a bit more complicated than nomac, but not that much. But of course if
>> you do not need packets to be sent ASAP, I agree that rtnet is overkill.
> 
> Right. But the problem, err, challenge is that this rate limiting has to
> be installed either into the switch/router that your RT box is attached
> to or into all nodes that may talk to it.

Right, you can not do this on RX traffic. But if you accept that the RT
packets have some way to be recognized (VLAN, IP TOS field, mac address,
whatever), you can configure the switches to give a higher priority to them.

-- 
                                          Gilles