Hi Jan, > 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?
Now I understand the "periodical transmission" of "memory region" better:) But Firewire multicasting/isochronous transmission is also packet-origented. The DMA controller will tranmit some data on fly/iso channel, if and only if the software has put data in the mapped memory, otherwise (there is no data in the mapped memory), the DMA controller of Firewire will do nothing. So the "automatic re-transmission of a certain memory area" is not supported in Firewire hardware. But I have two ideas for that: one is to deny the "automatic re-transmission....", e.g. in a process monitoring case, the sending node only sends the state data when the state has been changed by plant/application, while the receiving node only update its stored state data when a new data has arrived, otherwise it will deliver the old data to user/applicatoin, meaning that the process state has not been changed. Another idea is to support the "automatic re-transmission..." in software. So in the sending node, there is a realtime task that periodically retrieves and transmits the state of process, thru a shared memory or.... > Mmh, a lot of tasks, and I still didn't understand the > underlying synchronisation mechanisms and timing > requirements. I try to repeat it: > The Firewire controller can be instructed to transmit a > certain memory region (accessed via DMA) over and over again. > The Packet Management Module runs an RTAI(?) task at the > same(?) frequency of 8kHz to prepare this memory region. So, > how is THIS task synchronised with the hardware? > Does it retrieve the frequency from the controller by waiting > on the transmission? > My idea is, the PM module (or whatever middleware) doesnt need to be synchronized with the hw (e.g. firewire). The realtime task in PM module should be run at a frequency that is Not Higher than the frequency of hw, e.g. 8KHz in Firewire. The same, the application should also be run at a frequency that is Not Higher than the frequency of PM module (or whatever middleware). As a comparison, it's like the relation between passenger and bus: the passenger can take the bus everyday or even every week..... but the bus must go every 10 mins. There is no synchronization between passenger and bus, i.e. the bus will not wait for a late passenger. > And then the question is why we need an addition management > task between > the hardware and the user application? It may only increase > the overhead if the application has to run at 8 kHz as well > anyway. Already on mid-sized boxes, such task frequencies > will drive the system to its limits (remember typical > scheduling jitters of 30-60 us). > Well, the purpose to create a additional management task is to periodically collect the data from applications who wish to transmit sth on fly, and to multiplex these data to a single iso packet. Note that if the application can directly write some data the DMA-mapped area, these data will tranmitted as soon as possible as a single iso packet. In Firewire, each node can only transmit one iso packet for one channel, in each cycle, so the data from next application can only be transmitted in next cycle. This is not efficient, and may mess up the traffic on the network. > Yes, a widely hardware-agnostic API is a good design goal. > But don't try to invent it in the "clean room", i.e. without > constantly checking it against concrete implementation > scenarios on known hardware. In this case, try to consider > how both Firewire and Ethernet would fit into it. > A clean API can also mean an unusable API. ;) Yes, I will consider how both can fit, and do the comparison and of cousre discussion:) Also, I would like to hear more suggestions or questions from you. Yuchen ------------------------------------------------------- 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
