Thread: [RTnet-developers] Running an RTNET node over a non-rt network.
Brought to you by:
bet-frogger,
kiszka
|
From: Gilles C. <gil...@la...> - 2007-03-15 13:03:20
Attachments:
rtnet-remove-rtmac-hdr.diff
|
Hi,
I am asked to run a real-time networking application on a non real-time
network, so, I naturally thought about using RTnet.
But unless I am completely mistaken, it is not what RTnet is originally
made for. As far as I understood, in an RTnet network, the non real-time
trafic is tunneled through the real-time traffic by adding an rtmac
header with the RTMAC_FLAG_TUNNEL flag set. But since the other nodes on
the network I am on are non-rt, they do not understand the rtmac header.
So, I started hacking RTnet to get what I wanted, and since I believe it
may interest other users, I submit the patch here. I do not expect this
patch to be integrated as is, it is merely a one day hack, but it should
demonstrate my use-case of RTnet and hopefully influence RTnet
developers to take this use-case into account.
Regards.
--
Gilles Chanteperdrix
|
|
From: Saiful K. <sai...@gm...> - 2007-03-16 04:39:52
|
Hi Gilles, I have some confusions 1. U changed the protocol stack only, so it will work in nonRT linux over nonRTDM driver rite? 2. Then can the real time performance be achieved? 3. Can u please tell me how to use/install it in nonRT linux? (as when after patching i tried to configure using ./configure then I got error: checking for RT-extension... configure: error: *** RT-extended kernel not found in /lib/modules/2.6.20/build) Sorry if I asked any invalid questions. Thanks and regards Saiful On 3/15/07, Gilles Chanteperdrix <gil...@la...> wrote: > > Hi, > > I am asked to run a real-time networking application on a non real-time > network, so, I naturally thought about using RTnet. > > But unless I am completely mistaken, it is not what RTnet is originally > made for. As far as I understood, in an RTnet network, the non real-time > trafic is tunneled through the real-time traffic by adding an rtmac > header with the RTMAC_FLAG_TUNNEL flag set. But since the other nodes on > the network I am on are non-rt, they do not understand the rtmac header. > > So, I started hacking RTnet to get what I wanted, and since I believe it > may interest other users, I submit the patch here. I do not expect this > patch to be integrated as is, it is merely a one day hack, but it should > demonstrate my use-case of RTnet and hopefully influence RTnet > developers to take this use-case into account. > > Regards. > > -- > Gilles Chanteperdrix > |
|
From: Gilles C. <gil...@la...> - 2007-03-16 11:15:14
|
Saiful Khan wrote:
> Hi Gilles,
>
> I have some confusions
> 1. U changed the protocol stack only, so it will work in nonRT linux
> over nonRTDM driver rite?
The original RTnet already provides this support.
> 2. Then can the real time performance be achieved?
The real-time response is only achieved for packets directed to
real-time applications.
> 3. Can u please tell me how to use/install it in nonRT linux? (as when
> after patching i tried to configure using ./configure then I got
> error: checking for RT-extension... configure: error: *** RT-extended
> kernel not found in /lib/modules/2.6.20/build)
I am an RTnet newby myself, so I will not be of much help. The patch I
sent is not made for end users, but for RTnet developers as an example
of the modifications of the stack I would need, so you should not apply
it if you do not know what you are doing. However since the problem you
have is a user problem, I suggest you post to the rtnet-users mailing list.
--
Gilles Chanteperdrix
|
|
From: Wolfgang G. <wg...@gr...> - 2007-03-16 12:34:58
|
Saiful Khan wrote: > Hi Gilles, > > I have some confusions > 1. U changed the protocol stack only, so it will work in nonRT linux > over nonRTDM driver rite? > 2. Then can the real time performance be achieved? > 3. Can u please tell me how to use/install it in nonRT linux? (as when > after patching i tried to configure using ./configure then I got > error: checking for RT-extension... configure: error: *** RT-extended > kernel not found in /lib/modules/2.6.20/build) Well, RTnet requires a real-time extension. It cannot be used as-is with the standard Linux kernel (and without real-time it does not even make sense) > Sorry if I asked any invalid questions. I have the impression that you are not really aware of what RTnet is good for. Could you please tell use why you like to use it. Wolfgang. > Thanks and regards > Saiful > > On 3/15/07, Gilles Chanteperdrix <gil...@la...> wrote: >> Hi, >> >> I am asked to run a real-time networking application on a non real-time >> network, so, I naturally thought about using RTnet. >> >> But unless I am completely mistaken, it is not what RTnet is originally >> made for. As far as I understood, in an RTnet network, the non real-time >> trafic is tunneled through the real-time traffic by adding an rtmac >> header with the RTMAC_FLAG_TUNNEL flag set. But since the other nodes on >> the network I am on are non-rt, they do not understand the rtmac header. >> >> So, I started hacking RTnet to get what I wanted, and since I believe it >> may interest other users, I submit the patch here. I do not expect this >> patch to be integrated as is, it is merely a one day hack, but it should >> demonstrate my use-case of RTnet and hopefully influence RTnet >> developers to take this use-case into account. >> >> Regards. >> >> -- >> Gilles Chanteperdrix >> > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > RTnet-developers mailing list > RTn...@li... > https://lists.sourceforge.net/lists/listinfo/rtnet-developers > > |
|
From: Jan K. <jan...@we...> - 2007-03-18 10:22:15
Attachments:
signature.asc
|
Hi Gilles, Gilles Chanteperdrix wrote: > Hi, >=20 > I am asked to run a real-time networking application on a non real-time= > network, so, I naturally thought about using RTnet. >=20 > But unless I am completely mistaken, it is not what RTnet is originally= > made for. As far as I understood, in an RTnet network, the non real-tim= e > trafic is tunneled through the real-time traffic by adding an rtmac > header with the RTMAC_FLAG_TUNNEL flag set. But since the other nodes o= n > the network I am on are non-rt, they do not understand the rtmac header= =2E Before I misunderstand your patch: you run RTmac/TDMA on a non-RT network and you then need to use the tunnel (also) between RT and non-RT nodes? Have you considered the rtnetproxy as platform for your solution as well? Or do you see your approach as a potential replacement for the proxy? Jan |
|
From: Gilles C. <gil...@la...> - 2007-03-18 15:32:42
|
Jan Kiszka wrote: > Hi Gilles, > > Gilles Chanteperdrix wrote: > > Hi, > > > > I am asked to run a real-time networking application on a non real-time > > network, so, I naturally thought about using RTnet. > > > > But unless I am completely mistaken, it is not what RTnet is originally > > made for. As far as I understood, in an RTnet network, the non real-time > > trafic is tunneled through the real-time traffic by adding an rtmac > > header with the RTMAC_FLAG_TUNNEL flag set. But since the other nodes on > > the network I am on are non-rt, they do not understand the rtmac header. > > Before I misunderstand your patch: you run RTmac/TDMA on a non-RT > network and you then need to use the tunnel (also) between RT and non-RT > nodes? Have you considered the rtnetproxy as platform for your solution > as well? Or do you see your approach as a potential replacement for the > proxy? My aim is to run an RTnet node on a non real-time network, in order for real-time applications to avoid loosing determinism when they transmit or receive packets over network. But I would like the rest of the system to continue working as if RTnet was not there. I have tried rtnetproxy, but with rtnetproxy, arp requests/replies do not work, so that my non real-time applications do not work. So far, I have only tried to get the non real-time stuff working, so I am using the NOMAC discipline, and I suspect the patch I sent does not work with anything else. I even suspect that it does not work at all, since I am getting kernel bugs, and am not sure whether they are due to this patch, or to my real-time ethernet driver implementation. Anyway, I am open to any better solution. -- Gilles Chanteperdrix. |
|
From: Jan K. <jan...@we...> - 2007-03-18 21:21:28
Attachments:
signature.asc
|
Gilles Chanteperdrix wrote: > Jan Kiszka wrote: > > Hi Gilles, > >=20 > > Gilles Chanteperdrix wrote: > > > Hi, > > >=20 > > > I am asked to run a real-time networking application on a non real= -time > > > network, so, I naturally thought about using RTnet. > > >=20 > > > But unless I am completely mistaken, it is not what RTnet is origi= nally > > > made for. As far as I understood, in an RTnet network, the non rea= l-time > > > trafic is tunneled through the real-time traffic by adding an rtma= c > > > header with the RTMAC_FLAG_TUNNEL flag set. But since the other no= des on > > > the network I am on are non-rt, they do not understand the rtmac h= eader. > >=20 > > Before I misunderstand your patch: you run RTmac/TDMA on a non-RT > > network and you then need to use the tunnel (also) between RT and no= n-RT > > nodes? Have you considered the rtnetproxy as platform for your solut= ion > > as well? Or do you see your approach as a potential replacement for = the > > proxy? >=20 > My aim is to run an RTnet node on a non real-time network, in order for= > real-time applications to avoid loosing determinism when they transmit > or receive packets over network. But I would like the rest of the syste= m Keep in mind: Concurrent access of RT and non-RT to the same NIC for transmitting data may require some tweaking to manage non-RT traffic bursts. Even more problematic: receiving non-RT traffic over an RT-NIC can easily toast your systems determinism (message dispatching...). You will have to enforce some kind of traffic shaping towards the RTnet node as well. > to continue working as if RTnet was not there. I have tried rtnetproxy,= > but with rtnetproxy, arp requests/replies do not work, so that my non > real-time applications do not work. I guess ARP forwarding was not yet a use case for rtnetproxy. One could solve this by injecting incoming ARP replies into the Linux stack as well. Another open issue is forwarding UDP packets to non-RTnet ports. >=20 > So far, I have only tried to get the non real-time stuff working, so I > am using the NOMAC discipline, and I suspect the patch I sent does not Hmm, NoMAC is for demo purpose, not originally developed to solve real problems. BTW, how do you want to demux incoming packets if you kill the RTmac header? > work with anything else. I even suspect that it does not work at all, > since I am getting kernel bugs, and am not sure whether they are due to= > this patch, or to my real-time ethernet driver implementation. >=20 > Anyway, I am open to any better solution. >=20 I really recommend going the rtnetproxy path, adding the missing features to that module and/or establishing more hooks in the stack. Jan |