[Tinyos-devel] Re: 2.0.2 CC2420
J. Ryan Stinnett
jryans at rice.edu
Thu Jul 5 10:51:47 PDT 2007
David Moss wrote:
> So we have two votes for including the software address recognition from
> Mike and Ryan. There's not really an optional way of including it, except
> by have a completely separate CC2420ReceiveP in an app directory that
> overrides the default. Having two separate CC2420ReceiveP's would make
> configuration management more difficult.
>
> Instead of making two, how about we use software address recognition as the
> default as suggested and nudge someone to characterize both implementations
> at some point in a test bed to quantify the difference in performance? We
> know the address check is not optimized, but if performance really doesn't
> suffer that much, then the benefits outweigh the loss.
I don't mind doing the characterization, since after all I'm one of the
people pushing for the change. I've got a small 10 mote test bed
currently on idle, if that seems like it would suffice. Any suggestions
on specs or stats?
>
> As per Ryan's comments, CC2420Config.setAddressRecognition(bool on) and
> CC2420Config.isAddressRecognitionEnabled() have been added, along with an
> equivalent preprocessing #define: CC2420_NO_ADDRESS_RECOGNITION. The
> isAddressRecognitionEnabled() is not checked when performing SACK's, since
> we should always perform an address check when SACK'ing.
Sounds great, thanks for adding that in.
- Ryan
>
> Another unit test should be added for this functionality, but I don't have
> time to create it right now. I'll regression test the rest of the stack to
> make sure nothing broke and update CC2420BaseStation to use the new
> preprocessing definition configurations. After regression testing is
> complete, I'll commit these changes.
>
> Thanks for all your input guys,
> -David
>
>
>
> -----Original Message-----
> From: J. Ryan Stinnett [mailto:jryans at rice.edu]
> Sent: Wednesday, July 04, 2007 1:26 PM
> To: David Moss
> Cc: 'Chieh-Jan (Mike) Liang'; tinyos-devel at millennium.berkeley.edu
> Subject: Re: RE: [Tinyos-devel] 2.0.2 CC2420
>
> David Moss wrote:
>> I would be very hesitant to allow the baseline CC2420ReceiveP to perform
> its
>> former software address check to support this edge case because
>> acknowledgement performance may suffer as a whole, which we've already
> seen
>> and quantified to some degree.
>>
>> There are a few timing issues going on with acks in the background to take
>> into consideration: After the Tx mote sends its packet, the SPI bus must
> be
>> acquired by the Rx mote. This resource acquiring may add significant
> delay
>> depending on what else is going on with the SPI bus (flash, other task
>> handling). By the time the Rx mote acquires its SPI resource and is able
> to
>> download the packet, the Tx mote's ack wait period is winding down. The
> Rx
>> mote must SACK as fast as possible to ensure the ack is received by the Tx
>> mote within the ack wait window. The fastest way to SACK is to download
> the
>> first byte (length) and the second byte (fcf) to see if A) we have a valid
>> packet and B) if the packet requested an ack. If we wanted to test for
> the
>> address, we'd have to download several more bytes before being able to see
>> the destination address. True, it's only a few more bytes, but it's
>> certainly not optimized.
>>
>> Another way around this case is to do what the BaseStationCC2420 does,
> which
>> is override a module from the CC2420 stack with a version that does what
> you
>> want. I've made it fairly easy to do: there's an FCF_LENGTH parameter in
>> CC2420ReceiveP which is currently set to 2 (because the FCF is 2 bytes).
> By
>> setting it to 7, Receive will make sure the packet's length is at least 7
>> bytes, read those 7 bytes and SACK, then continue reading the rest of the
>> packet. Because we're reading in 7 bytes from the header before SACK'ing
>> instead of 2, the destination address will be available and we can check
> it.
>> (attached, this file isn't tested).
>
> I'm not sure I understand how reading these 7 bytes works around the
> issue of reading extra bytes in the paragraph above this one. I can see
> how having to download the entire packet before SACK would degrade
> performance, however if it can be done by getting only a few more bytes
> to check the address, I think that's great and should be available *as
> an option* but not be the default, since as you say it is not optimal.
>
> - Ryan
>
>> If other users agree that this really isn't an edge case and we should see
>> this software address check version as the default, then by all means it
>> should be in there. However, SACK's do not perform as well as hardware
>> ack's, and it's been my focus to get them optimized as much as possible.
>>
>> -David
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Chieh-Jan (Mike) Liang [mailto:cliang4 at cs.jhu.edu]
>> Sent: Wednesday, July 04, 2007 11:20 AM
>> To: David Moss
>> Cc: tinyos-devel at millennium.berkeley.edu
>> Subject: Re: [Tinyos-devel] 2.0.2 CC2420
>>
>>> .... If you want the base
>>> station to disable address recognition to sniff all packets, and also
> send
>>> out SACK's when it receives a packet with its address, that's another
>> issue.
>>> -David
>>>
>> I think this could be useful. In addition, adding address check should
>> not affect the two applications you mentioned: base station and sniffer.
>> Any thoughts?
>>
>> Thanks
>>
>> Mike
>>
>>> -----Original Message-----
>>> From: J. Ryan Stinnett [mailto:jryans at rice.edu]
>>> Sent: Tuesday, July 03, 2007 10:45 PM
>>> To: David Moss
>>> Cc: 'Chieh-Jan (Mike) Liang'; tinyos-devel at millennium.berkeley.edu
>>> Subject: Re: RE: [Tinyos-devel] 2.0.2 CC2420
>>>
>>> Does this have any effect on snooping with CC2420? Just to confirm, the
>>> address recognition feature needs to be disabled as in BaseStationCC2420
>>> before snooping will work, is that correct?
>>>
>>> Thanks,
>>> Ryan
>>>
>>> David Moss wrote:
>>>> Yup - there's a good reason for this. The destination address is
> checked
>>>> automatically by hardware while receiving the packet transmission. So
> by
>>>> the time the uC gets the signal that a new packet has arrived, the
> packet
>>>> has already gone through the address/pan check. Therefore, we don't
> need
>>> a
>>>> second address check in software before issuing a SACK.
>>>>
>>>> -David
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: David Moss [mailto:dmm at rincon.com]
>>>> Sent: Tuesday, July 03, 2007 9:45 PM
>>>> To: 'Chieh-Jan (Mike) Liang'
>>>> Cc: 'tinyos-devel at Millennium.Berkeley.EDU'
>>>> Subject: RE: [Tinyos-devel] 2.0.2 CC2420
>>>>
>>>> Yup - there's a good reason for this. The destination address is
> checked
>>>> automatically by hardware while receiving the packet transmission. So
> by
>>>> the time the uC gets the signal that a new packet has arrived, the
> packet
>>>> has already gone through the address/pan check. Therefore, we don't
> need
>>> a
>>>> second address check in software before issuing a SACK.
>>>>
>>>> -David
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Chieh-Jan (Mike) Liang [mailto:cliang4 at cs.jhu.edu]
>>>> Sent: Tuesday, July 03, 2007 7:41 PM
>>>> To: David Moss
>>>> Cc: tinyos-devel at Millennium.Berkeley.EDU
>>>> Subject: Re: [Tinyos-devel] 2.0.2 CC2420
>>>>
>>>> Something about SACK in the new CC2420 stack is not clear to me. In the
>>>> old implementation, before SACK is strobed, the mote ID is compared with
>
>>>> the packet destination address. However, this check is not performed any
>
>>>> more. Is there any reason behind this?
>>>>
>>>> Thank you
>>>>
>>>> Mike
>>>>
>>>> David Moss wrote:
>>>>> Just updated the CC2420 stack in preparation for 2.0.2. The file
>>>>> architecture has been re-arranged a little bit, making it easier to see
>
>>>>> how the stack is put together. As a result, the .platform files that
>>>>> reference the cc2420 were updated.
>>>>>
>>>>>
>>>>>
>>>>> Test results are included. Let me know if you have any issues.
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Recent Updates (from the readme):
>>>>>
>>>>> * New chip SPI bus arbitration working with Receive and Transmit.
>>>>>
>>>>>
>>>>>
>>>>> * Applied TUnit automated unit testing to CC2420 development
>>>>>
>>>>> > Caught lots of bugs, especially through regression testing
>>>>>
>>>>> > Source code in tinyos-2.x-contribs/tunit/
>>>>>
>>>>>
>>>>>
>>>>> * Applied TEP115 behavior to CC2420 SplitControl in Csma and Lpl
>>>>>
>>>>>
>>>>>
>>>>> * Updated ActiveMessageAddressC to provide the ActiveMessageAddress
>>>>> interface
>>>>>
>>>>> > Updated CC2420ConfigP to handle
>>>>> ActiveMessageAddress.addressChanged() and
>>>>>
>>>>> sync automatically upon address change events.
>>>>>
>>>>>
>>>>>
>>>>> * Updated CC2420Config interface to enable/disable sw/hw
>> acknowledgements
>>>>>
>>>>>
>>>>> * Updated CC2420ConfigP to share register editing through single
>>> functions
>>>>>
>>>>>
>>>>> * Acknowledge after packet length and FCF check out valid.
>>>>>
>>>>> > The destination address is confirmed in hardware, so we don't need
>>>>>
>>>>> to download the entire header before acking.
>>>>>
>>>>>
>>>>>
>>>>> * Moved the getHeader() and getMetadata() commands to an internal
>>>> interface
>>>>> called CC2420PacketBody, provided by CC2420PacketC
>>>>>
>>>>>
>>>>>
>>>>> * Separated core functionality into different sub-packages/directories
>>>>>
>>>>> > Updated micaz, telosb, intelmote2 .platform files
>>>>>
>>>>> > Logically organizes code
>>>>>
>>>>>
>>>>>
>>>>> * Updated some LPL architecture
>>>>>
>>>>> > Removed continuous modulation because it didn't work 100% and I
>>>>> don't have
>>>>>
>>>>> time to make it work.
>>>>>
>>>>> > Decreased backoffs and decreased on-time for detects, saving
> energy.
>>>>>
>>>>>
>>>>> * Updated to the new AMPacket interface; made the radio set the
> outbound
>>>>> packet's destpan after send().
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
> ------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> Tinyos-devel mailing list
>>>>> Tinyos-devel at Millennium.Berkeley.EDU
>>>>>
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>
>
>
>
More information about the Tinyos-devel
mailing list