[Tinyos-devel] ctp vs other radio clients

[Omprakash Gnawali]

On Sat, Dec 6, 2008 at 8:40 AM, Philip Levis <pal at cs.stanford.edu> 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.
>

Lets say queue is not NULL in the above case, and call goes down to
the CC2420 stack and somehow the busy state is shared among all the
clients? Did you get a chance to look at this concern I had:

"Is it possible that the busy state is stack-wide rather than per type
in the implementation of tep116? Is there one instance of StateC for
CC2420 stack (UniqueSendC.nc) ?"

In DefaultLplP.nc:

  command error_t Send.send(message_t *msg, uint8_t len) {
...
    if(call SendState.requestState(S_LPL_SENDING) == SUCCESS) {

My concern was if there is one SendState, this could happen?

- om_p