Thanks a lot. Jan.
>===== Original Message From Jan Kiszka <[EMAIL PROTECTED]> ===== >Howard Cai wrote: >> Jan, Thanks a lot for the clarification! >> >> I think, Without hardware and tdma, a simple (MAC) queuing and priority >> processing can be processed in rtnet_dev layer before putting into hardware >> for transmission. a sending manager task need to serve the transmission queue >> either periodically or whenever requests for sending in this case. >> > >I wonder on what condition for sending a packet you want to wait for at >this point? Empty hardware queue of the NIC? Kind of TDMA with a >self-driven cycle clock? > Basically, I am doing some experiments in a single RTNET node networking environment. In order to distinguish the priority of the packet towards L2 from above for sending, you do not want low priority packets to fill the ethernet buffer and potential higher priority packets delayed or dropped. this cause latency for sure even in light load situation. In this case, a sending task is need to registered at the protocl layer to serve the outgoing queue with the priority enforced. this task can be similar as the receiving task ( triggered by NIC intr and rtnetif_rx) in the stack manager. inter-status exchange between this task and the NIC driver might help. for example, if the NIC sending buffer is lower than some threshold, signal the higher layer retransmit if anything in the queue. This only give some preference to higher priority outgoing packets. >One may also consider to derive the NIC queue state from the >transmission IRQ handler reports. Those IRQs get triggered when the NIC >is able to release the associated output buffer. Currently RTnet only >lets the NIC release the related rtskb back to its owner, no information >about the NIC's hardware queue state is maintained. Unfortunately, this >release does not always seem to happen right after the actual >transmission of a single packet. Some NICs perform this only when a >bunch of buffers are releasable. Not good for hard-RT when an event >depends on the context of other, rather unrelated RT or non-RT activities. > >> Of course the receiving is still a issue and so does the hardware network >> bandwidth management. >> > >As long as you cannot control the input stream of packets reaching a >node, that node is always threatened by the indeterministic load. You >cannot decide who (i.e. which task at which prio) is to receive the >packet until you were able to look the packet content. That's why RTnet >with TDMA demand closed, TDMA-only networks to function - you already >have to control the transmission on ALL node. > Yes, for real RT communication, you have to control everything in the network, the sender, the receiver and the network media management. Regards, Howard. ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
