Gilles Chanteperdrix wrote: > 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
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. > > 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. > > Anyway, I am open to any better solution. > I really recommend going the rtnetproxy path, adding the missing features to that module and/or establishing more hooks in the stack. Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/rtnet-developers
