Jan Kiszka escreveu: > Paul Regnier wrote: > >> Dear Karl, >> >> I'am working with Mark on some experiments using TDMA and I have some >> more doubts. >> What happens if the master has no stlot ? In such a case, what should be >> the minimum offset >> after the Sync frame ? >> > > If the master does not have to transmit any data (no RTcfg?) or uses > some time slot later in the frame, you could even set the offset to > zero. Of course, no real node will ever be able to hold that schedule, > but it will then transmit as soon as possible, right after receiving the > Sync frame. > > >> Using anoter discipline we are developping, we observe the folllowing >> fact. Whe the transmission of a >> maximum size frame (64b) comes just after the transmission of a mimimum size >> frame (1518b), this transmission takes over 250us, When various maximum >> > > (You either mixed up the number or the terms... :->) > > Sure. A cut & copy side effect... Sorry >> frame are sent in a row, >> the first interarrival time is 230us. Thereafter, all other values are >> about 130us, as expected on a 100Mbps >> Ethernet medium. >> > > Might be some effect of the NIC or its driver. Do you happen to have > recorded the traffic on the wire with some sniffer (either on a third > node if your switch allows this or on both the sender and the receiver)? > If so, what do those packet timestamps tell? > > No. We are using a broadcast configuration. One station sends messages to another and the third record the timetamps. >> We believe that the overhead of the first interval is due to the copy of >> the message to the buffer >> of the Ethernet card (rtl8139, using DMA). Just a kind of pipeline >> effect. Do you think this is the case ? >> > > Do you send out identical packets? Yes. > Or why should there only be an impact > on the first packet? > > Here comes our interpratation: our first timestamps is recorded when the small frame arrives. This small frame suffers from a small "copy to buffer" delay (10us). Then the second timestamps is recorded wen the second frame arrives. As this seond frame is 1518b long, it suffers from a copy delay of over 100us. Added to the 121.4us of the transmission delay, the 230us delay observed is explained.
When the third frame arrives, and all others after, as they have a maximum size, they all suffers from the same delay, and, consequently, their interarrival times are exactly 130us. In other words, the "copy to buffer" delay still happens, but as we just measure interarrival times, we cannot observe it between the reception of two frame of the same size. > However, you could additionally analyze your time using some system > tracer, either the I-pipe function tracer or LTTng (for the latter, you > may have to add some further ad-hoc trace points to RTnet, only RTDM and > the Xenomai core are instrumented so far). > > We are in a hurry to finalze a paper we would like to submit to SBRC. However, we may use such tools in a near future. As always, thanks a lot for your reactivity, Paul PS: We are owning to RTnet the code of our new discipline. Brasilian time is short !!! Our problem is that the integration to the build system is not completely working. We still have some problems with the configuration step. Also, our code is not as clean as it should be. However, we will soon provide a link where the download of our code will be possible. ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
