[Tinyos-devel] PacketLink interface, CC2420 impl, problems withBroadcast packets TinyOS 2.0.2.2

[David Moss]

I'm going over specifications right now.  It's been awhile since the whole
broadcast ack thing has come up.

The argument for ack'ing a broadcast message is that the transmitter can
know that at least one other node got the message.  The argument against it
is exactly as you've pointed out.  In either case, SACKs should behavior
just like HACKs on the CC2420.  

-David



-----Original Message-----
From: tinyos-devel-bounces at Millennium.Berkeley.EDU
[mailto:tinyos-devel-bounces at Millennium.Berkeley.EDU] On Behalf Of J. Ryan
Stinnett
Sent: Thursday, September 06, 2007 11:25 AM
To: Razvan Musaloiu-E.
Cc: tinyos-devel at Millennium.Berkeley.EDU
Subject: Re: [Tinyos-devel] PacketLink interface, CC2420 impl, problems
withBroadcast packets TinyOS 2.0.2.2

Alright, that may be true, as I haven't check the CC2420 specs in a 
while.  However, in most cases it is not useful to ACK a broadcast 
packet (at least with a hardware ACK), since multiple nodes would try to 
send an ACK to the same node at about the same time, causing a 
collision.  Perhaps this was in mind when the ACK handling for 
broadcasts in the radio stack was written?  I imagine David will have 
some input here.

- Ryan

Razvan Musaloiu-E. wrote:
> Hi!
> 
> On Thu, 6 Sep 2007, J. Ryan Stinnett wrote:
> 
>> Avinash -
>>
>> Broadcast packets are not ACKed at all.
> 
> If a broadcast packet has the 'Acknowledge request' set then it will be 
> acked by the CC2420 chip.
> 
> -- 
> Razvan ME
> 
>> If I understand correctly, you are checking in the sendDone event 
>> whether or not the packet was ACKed, and retrying if it was not, 
>> correct?  This check should not be performed on broadcast packets 
>> since ACKs are never sent for them.
>>
>> - Ryan
>>
>> Avinash Sridharan wrote:
>>> Hi All,
>>>  I am not sure if this is the right forum to send this mail, or 
>>> should I be sending it to the TinyOS-help mailing list.
>>>
>>> I was using the the PacketLink interface on the Tmote Sky's with the 
>>> CC2420 stack. In my code I have broadcast beacons that are send out 
>>> at periodic intervals. When I started using the PacketLink interface 
>>> I started seeing a considerable drop in my throughput (this is 
>>> observed using logs from the mote).
>>>
>>> I added some code to see the number of retransmission attempts for 
>>> each packet being sent out. In my test case I had a fully connected 
>>> network (with all links having a PRR of ~ 1). Ideally I should be 
>>> seeing all packets being ACKED and the number the sent attempts on 
>>> packets being 1. This was the case for the packets that were being 
>>> unicasted however for the broadcast packets the transmission attempts 
>>> were always the maximum number of retries and they were never ACKED 
>>> (this was true for all broadcast packets).
>>>
>>> On digging a bit deeper I realised that the CC2420PacketC (which 
>>> provides the PacketAcknowledgement interface) does not check for the 
>>> destination address and simply returns the ACK field in the metadata. 
>>> Once I added a condition for the checking the broadcast address (and 
>>> always returning true for BROADCAST), performance returned to normal.
>>>
>>> Is this a valid bug ? Is the fix correct, or should this condition be 
>>> handled at some other point ?
>>>
>>> regards,
>>> Avinash
>>>
>>>
>>> -- 
>>> Phd Dept. of Electrical Engineering
>>> University of Southern California
>>> http://www-scf.usc.edu/~asridhar
>>>
>>>
>>
> 
> 
_______________________________________________
Tinyos-devel mailing list
Tinyos-devel at Millennium.Berkeley.EDU
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel