15 messages in net.java.dev.spots.devRe[3]: Radio update, update| From | Sent On | Attachments |
|---|---|---|
| Ron Goldman | Mar 11, 2009 1:37 am | |
| John Daniels | Mar 11, 2009 2:01 am | |
| Ron Goldman | Mar 11, 2009 2:15 am | |
| John Daniels | Mar 11, 2009 2:46 am | |
| Markus Bestehorn | Mar 11, 2009 6:24 am | |
| Bart Braem | Mar 11, 2009 6:52 am | |
| Robert Taylor | Mar 11, 2009 7:24 am | |
| John Daniels | Mar 11, 2009 7:56 am | |
| Bart Braem | Mar 11, 2009 8:11 am | |
| Kurt Smolderen | Mar 11, 2009 11:04 am | |
| Ron Goldman | Mar 11, 2009 4:25 pm | |
| Ron Goldman | Mar 11, 2009 4:47 pm | |
| Ron Goldman | Mar 11, 2009 6:13 pm | |
| Ron Goldman | Mar 11, 2009 6:26 pm | |
| Stephan Kessler | Mar 16, 2009 12:04 am |
| Subject: | Re[3]: Radio update, update | |
|---|---|---|
| From: | Ron Goldman (Ron....@sun.com) | |
| Date: | Mar 11, 2009 6:26:42 pm | |
| List: | net.java.dev.spots.dev | |
On Mar 11, 2009, at 8:11 AM, Bart Braem wrote:
On 11 Mar 2009, at 15:56, John Daniels wrote:
I think removing the random delay (which might be zero) before the first transmission is ill-advised and may well cause problems. My understanding is that this delay is supposed to reduce the risk of nodes that simultaneously receive and forward packets getting immediate collisions. By standardizing on zero delay before the first attempt I guess the number of collisions will increase. Ron: what do you think?
The standard says that you can remove this delay, but we strongly advise against it. It will often increase the number of collisions. Things will certainly go wrong in case two nodes react to the same external event. But again, we have no hard data to prove this.
John & Bart,
Your point is well taken. The question is where should the delay to avoid two nodes responding "simultaneously" be in the radio stack & is it a penalty that every transmission should suffer.
Right now the LowPan code to forward a multihop broadcast adds a random delay (0-130 msecs) before retransmitting the packet. This is done to try to minimize collisions as the broadcast spreads across the network. I do not think that the 0-7 msec delay that is the default for the CSMA algorithm would help much in this case.
I also don't see how the initial delay helps for a node that just wants to send off a message (not triggered by an external event). All it does is slow things down. I think it is better for application writers to explicitly include a delay before responding to a received radio message if they know that other nodes will also respond. This is what we do with the Hello message broadcast out to discover SPOTs: the OTA code that generates the reply makes sure to delay a random amount of time (0-100 msec) before transmitting its response.
Does this sound reasonable?
-- Ron --