> In other words: Multicasting? Or where is the difference? Yes, you can also call it Multicasting. But IMO, the IP multicasting on ethernet is technically different from the multicasting on Firewire.As far as I know, in IP/Ethernet, a node needs to register itself in a certain multicast group if it wants to receieve the packet from that group, while in Firewire iso, the listening node only needs to tune its hardware, so more "radio-like"-:).
> So much for the Ethernet low-level world. Firewire seems to have a clean model by allowing to filter those channels in hardware, doesn't it? And how is the periodical.transmission managed in Firewire? Does the driver/stack have to interact for each isochronous packet or only if anything else than a linear memory stream is transmitted. I.e. what will you have to do for transmitting always the some memory region (e.g. some process states), and how to synchronise any access to this memory? Yes, the Firewire multicasting is more conveninet. The peroid is 125us, which means the "bus" on each channel goes every 125us. So the application can have a maximum freq as 8KHz. I dont really understand the synchronization problem you mentioned. My idea is the application should be totally decoupled from the lower layer, e.g Packet Management Module. What the application does is to deliver its data to PM Module and/or wait for the data from other nodes. But the PM Module is only responsible to index the data from applications, if there is any, like the bus stop. But the bus still goes in every 125us even there is no passenger. So in the case of process state monitoring, it is the application's responsibility to deliver the state data to PM Module in time, i.e. before the bus goes. > Well, for me the need for a new API depends on what extra features Firewire may give us compared to multicasting. With respect to packet oriented multicasting, IP already comes with such an interface, it "only" has to be added to the RTnet core. If Firewire also manages periodical re-transmissions of memory regions in hardware, one may think about a fitting API again. The IP multicasting is different from Firewire multicasting, so I am wondering if we can use the same BSD interface for Firewire. A possible way is to keep the naming of the new APIs the same as from BSD, but change the internals. Again, I dont really understand the "re-transmissins of memory region in hardware", could you explain more? > Shared skbs would be required if we want to have multiple local receivers of multicasted packets or broadcast streams. Whatever solution might be found, it will likely increase the complexity of the reception path compared to the current version. If we deny this as a first approach, things would certainly be easier. However, it may significantly degrade the usability of RTnet in non-trivial application scenarios. Just to give a brainstorming idea:). Maybe we can first deny rtskb sharing, but let the multiple local receivers for a certain rtskb be possible, i.e. let each socket pay for a "shared" rtskb.The realtime demultiplexing task in PM module/stack_mgr in RTnet can not be preempted by the waken up applications. That means the demultiplexng task only copys the rtskb to each application, rasie the corresponding semaphore without being preempted. So it can kfree the rtskb (to NIC) before return. Then all the waken up applications can be executed in order of priority. Of coz, the negative point of this solution is we need more memory, which maybe a problem for certain embedded systems. Yuchen -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 2005年1月23日 17:22 To: Zhang Yuchen Cc: 'rtnet-developers'; 'Orlic, B.'; 'Peter Visser' Subject: Re: [RTnet-developers] Firewire iso in RTnet/channel based broadcasting in distributed control Zhang Yuchen wrote: > Hi, Jan, > these days I am thinking of how to integrate the Firewire iso into > RTnet stack. To make the work more general/not-firewire-specific, I > got an idea to introduce the channel based broadcasting, where the > Firewire iso is one implementation. In other words: Multicasting? Or where is the difference? > > In channel based broadcasting, active node should choose one channel > to put its packet on fly, while the passive node tunes itself (in > hardware or in > software) to that certain channel to receive the packet. One node can > listen to multiple channels at the same time, but may only use one > channel to "radio" its packet. Compared with traditional > point-to-point communication, like on Ethernet, the channel based > broadcasting fits better within the distributed control system. > Because in distributed control system, almost any communication is > time-triggered, e.g. the encoder->controller->actuator in position > control. Also some communication is one to many, so really like a radio, the channel based broadcasting can be used here without any extra > overhead. Ethernet cards also support this scenario to some degree by offering to register multiple MAC addresses or MAC hash keys on which the cards may listen for incoming packets (additionally to broadcasts and its own MAC). Very comfortable and easy to schedule are cards which support MAC lists. Unfortunately, some cheaper models only support those hash keys, making live harder as you have to detect key collisions in order to estimate system load due to unwanted packets (working on real-time can be hard...). So much for the Ethernet low-level world. Firewire seems to have a clean model by allowing to filter those channels in hardware, doesn't it? And how is the periodical transmission managed in Firewire? Does the driver/stack have to interact for each isochronous packet or only if anything else than a linear memory stream is transmitted. I.e. what will you have to do for transmitting always the some memory region (e.g. some process states), and how to synchronise any access to this memory? > > To introduce the channel based broadcasting, one or more extra modules > need to be created in the stack. > One is the API module, which is to provide to the application a set of > high level primitives and hide all the internal details. (This could > be done by making an extension to the RTDM module.) Second is the > Packet Management module, which is to (de)multiplex the messages. > There may be several processes on one node, (the process may be called > Server here since they are actively sending some message), hence the > PM module is responsible to put all the messages into one packet with > an index. Also in the receiving side, the PM module should also > demultiplex the incoming packet according to the index. > > It may be asked that where to do the allocation and subscription of > channels. Well, this could be done in PM module also. But since > distributed control system is not that flexible, and normally not need > to be, so this work can also be done during the offline configuration phase. Well, for me the need for a new API depends on what extra features Firewire may give us compared to multicasting. With respect to packet oriented multicasting, IP already comes with such an interface, it "only" has to be added to the RTnet core. If Firewire also manages periodical re-transmissions of memory regions in hardware, one may think about a fitting API again. > > Of course, we also need a hardware/fieldbus-specific module to > implement all the high-level primitives. For the hardware, as far as I > know, Firewire, CAN, even Ethernet can be a choice. In my opinion, > Firewire fits best, both on the latency and the convenience (the > tuning to multiple channels is supported in Firewire chip). > Stepping one layer lower from IP, the Packet Socket API of Linux also provides some interface for joining and leaving multicast groups - independent of the transmission media. Again it's packet oriented, so it has to be checked if this matches the Firewire model. > Ok, so far, this is my rough idea. Any correction and addition is > welcome-:). > It is definitely an interesting topic, especially as many high-layer protocols like RTPS can also make use of multicast / broadcast channel features. Multicast is on our roadmap for quite a while now. But it has been postponed due to some still open design question I also discussed in this mail: http://www.mail-archive.com/rtnet-users%40lists.sourceforge.net/msg00454.htm l Shared skbs would be required if we want to have multiple local receivers of multicasted packets or broadcast streams. Whatever solution might be found, it will likely increase the complexity of the reception path compared to the current version. If we deny this as a first approach, things would certainly be easier. However, it may significantly degrade the usability of RTnet in non-trivial application scenarios. Jan ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ RTnet-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rtnet-developers
