2009/8/17 Razvan Musaloiu-E. <[email protected]> > Hi! > > > On Wed, 12 Aug 2009, Rémi Villé wrote: > > 2009/8/12 Omprakash Gnawali <[email protected]> >> >> On Tue, Aug 11, 2009 at 9:31 AM, Rémi Villé<[email protected]> wrote: >>> >>>> 2009/8/11 Rémi Villé <[email protected]> >>>> >>>>> >>>>> 2009/8/10 Omprakash Gnawali <[email protected]> >>>>> >>>>>> >>>>>> On Mon, Aug 10, 2009 at 7:14 AM, Rémi Villé<[email protected]>> >>>>>> wrote: >>>>>> >>>>>>> 2009/8/6 Rémi Villé <[email protected]> >>>>>>> >>>>>>>> >>>>>>>> 2009/8/6 Rémi Villé <[email protected]> >>>>>>>> >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I would like to count the number of transmissions/retransmissions >>>>>>>>> during >>>>>>>>> a simulation with TOSSIM. >>>>>>>>> For now, I only need to write this count on stdout using gdb(), but >>>>>>>>> I >>>>>>>>> dont know where is the ideal place to add it, I would like to >>>>>>>>> estimate the >>>>>>>>> number of (re)transmissions with as much accuracy as possible. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Rémi >>>>>>>>> >>>>>>>> >>>>>>>> It's dbg(). >>>>>>>> >>>>>>> >>>>>>> I must do that because I have modified the CtpRoutingEngine to use >>>>>>> node to >>>>>>> node similarity, and if I count the number of transmission using only >>>>>>> Send.sendDone (of CollectionC.CollectionSenderC), I have not the >>>>>>> total >>>>>>> number of retransmission/retransmission... >>>>>>> >>>>>> >>>>>> You can put your debug statements in the AM layer. >>>>>> >>>>>> - om_p >>>>>> >>>>> >>>>> I didn't find exactly where to put the dbg statement in the AM layer >>>>> yet, >>>>> but maybe it would be a better idea to measure the data throughput >>>>> (packets >>>>> per second delivered) in the java application, it may be equivalent and >>>>> costless for nodes in a future real deployment test. >>>>> >>>> >>>> I think the good place to put the dbg statement is in "event void >>>> Model.sendDone(message_t* msg, error_t result){...}" in the >>>> tos/lib/tossim/TossimActiveMessageC.nc file, but I'm not sure it >>>> includes >>>> Ack and re-transmissions... >>>> >>>> >>> CTP retransmissions are done using the AM layer: each retransmission >>> is a new packet as far as the AM layer is concerned. As long as you >>> instrument the AM layer, you should catch all the retransmissions. >>> >>> - om_p >>> >>> >> Thanks for your help, I think I can distinguish ack and other transmission >> thanks to >> tossim_metadata_t* metadata = getMetadata(msg); >> and >> metadata->ack != 0 >> >> > You can take a look in the TossimPacketModelC.nc to see how the ack field > is used. It's set to TRUE when the .requestAck is called and then is > returned as the answer for the .wasAcked. The model is suppose to set it to > FALSE if the packet did not get to the destination. > > So, to make thinks clearer: there is ack packet in TOSSIM. The > PacketAcknowlegements interface is simulated just by tracking in a variable > (the ack from metadata) if the packet got it to the other end or not. > > It's not a crucial question for me now, but is there a parameter in >> tossim_metadata_t, tossim_header_t or tossim_footer_t which can allow me >> to >> distinguish transmissions and re-transmissions? >> >> > The re-transmissions in CTP are application layer re-transmissions. Said > differently, CTP doesn't use the PacketLink interface that can automatically > retransmit the packet up a certain number of times. So I think you should > probably instrument the CtpRoutingEngineP.nc to print at each send something > informations about the packet that will allow you to know when the same > packet is sent. There might be already some dbg statements that do this > already there. :-) > > Note: I presume you are not using the CC2420sim. > > All the best! > Razvan ME
You can take a look in the TossimPacketModelC.nc to see how the ack field is > used. It's set to TRUE when the .requestAck is called and then is returned > as the answer for the .wasAcked. The model is suppose to set it to FALSE if > the packet did not get to the destination. > > So, to make thinks clearer: there is ack packet in TOSSIM. The > PacketAcknowlegements interface is simulated just by tracking in a variable > (the ack from metadata) if the packet got it to the other end or not. > So ack field sets to FALSE is just a tool for TOSSIM to know if a packet got to the destination? but shouldn't be take in consideration in a total number of transmissions if we want this count to be more realistic as possible? Because in real mode, there's no way for a mote to know if a message that it should receive hasn't be received (it surely must be done by the sender with a time-out). So when ack is TRUE it means that the sender waits for this message to be acked, but it's not an ack? So if the sink never sets ack to TRUE it means that it never requests its messages to be acked? Rémi
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
