[Tinyos-devel] ctp vs other radio clients

[Geoffrey Werner-Allen]

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,

-gwa-

geoffrey werner-allen :: 617.694.7261 :: www.eecs.harvard.edu/~werner


On Mon, Oct 27, 2008 at 8:28 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.
>
> Hrm. That's weird. Please read TEP 116: send should  return EBUSY iff
> it has returned SUCCESS to a prior call and has not yet signaled
> sendDone.
>
> This suggests that it's a bug in CTP where it calls send multiple times.
>
> Phil
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20081206/f82b0176/attachment-0001.htm