[Tinyos-devel] ctp vs other radio clients

[Philip Levis]

On Dec 6, 2008, at 8:40 AM, Philip Levis wrote:

>
> On Dec 6, 2008, at 8:06 AM, Geoffrey Werner-Allen wrote:
>
>> Couldn't this happen if, as Brany suggests, another component is
>> using the radio stack?  I've also used CTP with other protocols
>> (including FTSP) and recall seeing it hit this corner. We were
>> implementing reliability at a higher level so it wasn't fatal, but I
>> believe I tracked it down to CTP trying to forward a packet while
>> FTSP broadcast messages were being sent. With LPL these occupy the
>> stack for a potentially long period of time (half a second at our
>> duty cycle), and so the chances of DefaultLPLP.nc returning BUSY
>> from Send.send() was pretty high. (I believe the default FTSP
>> traffic rate is one global message / 10 seconds, so using a sleep
>> interval of 1/2 second this means that you have a 1/20 chance of
>> colliding with a FTSP broadcast message.)
>>
>> Best,
>
> No. Please read TEP 116. Each AMSenderC has a reserved slot in the AM
> transmit queue. AMSend.send returns EBUSY iff there is an outstanding
> AMSend.send. The text reads:
>
> The ``Send`` and ``AMSend`` interfaces have an explicit queue of
> depth one.
>
> The implementation:
>
>     command error_t Send.send[uint8_t clientId](message_t* msg,
>                                                 uint8_t len) {
>         if (clientId >= numClients) {
>             return FAIL;
>         }
>         if (queue[clientId].msg != NULL) {
>             return EBUSY;
>         }
>
> Of course, a very busy link layer causes longer delays between send
> and sendDone, such that it's more likely the higher layer will issue a
> second send before the sendDone comes in. But if it hasn't called
> send(), then it should not get EBUSY.

NB:

If the underlying AM layer can return EBUSY when there is no  
outstanding packet transmission (no pending sendDone), then this could  
occur (AMQueueImpl.nc:110). This might also make sense given Brano's  
earlier observation that adding the retransmit timer solved the  
problem. So I'm going to look into the CC2420 stack. It would also  
explain why the problem occurs on motes but not in TOSSIM.

Phil