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....
Ah, this make FireWire even more Ethernet-like ;). And it also means that the IP and Packet Socket multicasting API of Linux should be adaptable, we may only need some tweaking where it comes to FireWire specific addressing at the lowest level.
BTW, the "channel" abstraction for outgoining packets could be passed from the user to the stack through the socket priority field (which is tranfered to rtskbs upon packet creation). This value, formerly only expressing the priority when queuing an rtskb in the TDMA layer, now also contains a bit range which is used to address specific TDMA2 output time slots in latest RTnet. Why not using the same mechanism for addressing the respective FireWire iso channel?
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.
Well, even your real scenario needs some sychronisation: the bus driver and the passenger have to coordinate the bus entry - otherwise someone might get squeezed... ;)
For FireWire, such "squeezing" may happen if memory is changed by the CPU while the controller is accessing it via DMA (as long as the DMA access is not atomical, but this is too hardware-depended).
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.
Ok, I see this makes sense if you share an iso channel between multiple local users. But it would become redundant if there is only a single user, doesn't it?
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
Jan
smime.p7s
Description: S/MIME Cryptographic Signature
