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
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
