[Tinyos-devel] ctp vs other radio clients

[Geoffrey Werner-Allen]

I'm pretty sure there IS one SendState and this was my concern exactly,
although Om states it more clearly.

Best,

-gwa-

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


On Sat, Dec 6, 2008 at 11:56 AM, Omprakash Gnawali <gnawali at usc.edu> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20081206/7dc59960/attachment.htm