[Tinyos-devel] ctp vs other radio clients

[Omprakash Gnawali]

On Fri, Dec 5, 2008 at 4:37 PM, Philip Levis <pal at cs.stanford.edu> wrote:
>
> On Oct 27, 2008, at 5:36 PM, Branislav Kusy wrote:
>
>> guys,
>>
>> is it allowed to use the radio (ie ActiveMessageC) while using Ctp? if
>> not, should it be allowed? most of my applications require it...
>>
>> i couldn't find anything about this in tep123, but i found this
>> comment
>> in CtpForwardingEngineP.nc,v1.17:
>>
>> line 487:
>>       subsendResult = call SubSend.send(dest, qe->msg, payloadLen);
>> ....
>> lines 509-519:
>>       else if (subsendResult == EBUSY) {
>>       // This shouldn't happen, as we sit on top of a client and
>>         // control our own output; it means we're trying to
>>         // double-send (bug). This means we expect a sendDone, so just
>>         // wait for that: when the sendDone comes in,  we'll try
>>         // sending this packet again.
>>       dbg("Forwarder", "%s: subsend failed from EBUSY.\n", __FUNCTION__);
>>         // send a debug message to the uart
>>         call CollectionDebug.logEvent(NET_C_FE_SUBSEND_BUSY);
>>       }
>>
>> if there are other radio clients, subsendResult may be EBUSY even if
>> we
>> don't double send. therefore, we should just call
>>       startRetxmitTimer();
>>
>> if we don't do this, ctp basically hangs forever.
>>
>> i've had this problem for a long time - ctp hanging on me for no good
>> reason. my test application can reproduce it in a few seconds. i
>> tested
>> calling startRetxmitTimer() from the EBUSY case and it fixed the
>> problem. i'm not sure if it didn't introduce any other problems,
>> though.
>
>
> Sorry it took me so long. Finally got to this. Can you try this fix?
>
> Change the line in Send.send that reads:
>
> if (radioOn && !call RetxmitTimer.isRunning()) {
>
> to
>
> if (radioOn && !sending) {
>
> I think the bug is that the Retxmit timer has fired, the event is a
> task on the queue, but the task calling Send is ahead of it. From the
> timer system's standpoint, the timer is no longer running, but...
>
> That being said, I'm not able to recreate the hanging bug. But this
> logic makes it that EBUSY never occurs.
>

I tried your change just now:
346,347c346
<       //      if (radioOn && !call RetxmitTimer.isRunning()) {
<       if (radioOn && !sending) {
---
>       if (radioOn && !call RetxmitTimer.isRunning()) {

and I still see SUBSEND_BUSY:

1228544531.027306: NET_C_FE_FWD_MSG 32 169 0 6633 0
1228544531.027372: NET_C_FE_SENDQUEUE_EMPTY 6634 0
1228544531.441403: NET_C_FE_RCV_MSG 37 157 2 6635 0
1228544531.441484: NET_C_FE_FWD_MSG 37 157 0 6636 0
1228544531.441542: NET_C_FE_SUBSEND_BUSY 6637 0
1228544531.441599: NET_C_FE_SENDDONE_WAITACK 30 183 0 6638 0
1228544531.441656: NET_C_FE_SENT_MSG 30 183 0 6639 0
1228544531.441723: NET_C_FE_SENDQUEUE_EMPTY 6640 0
1228544531.460397: NET_C_FE_RCV_MSG 34 174 2 6641 0
1228544531.460464: NET_C_FE_FWD_MSG 34 174 0 6642 0
1228544531.460521: NET_C_FE_SENDQUEUE_EMPTY 6643 0

- om_p