2009/8/17 Razvan Musaloiu-E. <[email protected]>
> Hi!
>
>
> On Mon, 17 Aug 2009, Rémi Villé wrote:
>
> 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 things 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?
>>
>
> Yes.
>
> but shouldn't be take in consideration in a total number
>> of transmissions if we want this count to be more realistic as possible?
>>
>
> True.
>
> 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).
>>
>
> The best place to count the lost acks might be this function from
> CpmModelC.nc:
>
> 171 void sim_gain_ack_handle(sim_event_t* evt) {
> 172 // Four conditions must hold for an ack to be issued:
> 173 // 1) Transmitter is still sending a packet (i.e., not
> cancelled)
> 174 // 2) The packet requested an acknowledgment
> 175 // 3) The transmitter is on
> 176 // 4) The packet passes the SNR/ARR curve
> 177 if (requestAck && // This
> 178 outgoing != NULL &&
> 179 sim_mote_is_on(sim_node())) {
> 180 receive_message_t* rcv = (receive_message_t*)evt->data;
> 181 double power = rcv->reversePower;
> 182 double noise = packetNoise(rcv);
> 183 double snr = power - noise;
> 184 if (shouldAckReceive(snr)) {
> 185 signal Model.acked(outgoing);
> 186 }
> 187 }
> 188 free_receive_message((receive_message_t*)evt->data);
> 189 }
>
> The requestAck will be TRUE if the sender did a .requestAck on the packet
> and the Model.acked is signaled if the packet will really arrived at the
> sender.
>
> So when ack is TRUE it means that the sender waits for this message to be
>> acked, but it's not an ack?
>>
>
> In .send the ack is TRUE means the sender is requesting for an ack. In
> .sendDone the ack is TRUE if the ack packet was properly received.
>
> So if the sink never sets ack to TRUE it means that it never requests its
>> messages to be acked?
>>
>
> This depends on where do you look at the ack. :D
>
> --
> Razvan ME
Thanks for your help,
> So when ack is TRUE it means that the sender waits for this message to be
>> acked, but it's not an ack?
>>
>
> In .send the ack is TRUE means the sender is requesting for an ack. In
> .sendDone the ack is TRUE if the ack packet was properly received.
>
> So if the sink never sets ack to TRUE it means that it never requests its
>> messages to be acked?
>>
>
> This depends on where do you look at the ack. :D
I was looking at "event void Model.sendDone(message_t* msg, error_t
result){...}" in the tos/lib/tossim/TossimActiveMessageC.nc file, and I
observed that the ack field was never set to TRUE for the sink (so no ack
properly received).
I've just test in AMSend.send and ack field always at FALSE for the sink, so
it's like if in TOSSIM no acks are simulated for the sink, at this layer.
Anyway, I understand that acks are only simulated on the sender side.
So the best I can do now to count the number of transmissions of one node
with TOSSIM is to increment a counter when .sendDone is signaled. Always in
.sendDone, if ack field is TRUE, I can increment an other counter of "number
of ack sent by other motes", if it's FALSE I can increment on other counter
of "number of ack didn't received because the initial message didn't reach
the receiver or the ack didn't reach the initial sender". Maybe I miss
someting, but the latter counter is not very accurate to count the total
number of transmissions.
Rémi
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
