On Fri, Oct 22, 2010 at 9:37 PM, Dongyu Yang <yangdy.n...@gmail.com> wrote:
>>
>> Hello!
>> I set up one network containing four Node and one Root, and use "drip" to
>> disseminate command, and use "ctp" to collect data.The Root disseminates
>> command every 200 ~ 700 ms (randomly), and the Node use "ctp" to send
>> data to the Root when receive the command from the Root. I find the Node
>> can receive the Root dissemination command, but can nerver send out data
>> after about several minutes (about 5 minutes). And I find ever time when
>> call Send.send(), the return value is EBUSY. And I find every time it
>> return form
>> the Send.send() command in the component CtpForwardingEngineP as bellow:
>>
>>
>> command error_t Send.send[uint8_t client](message_t* msg, uint8_t len) {
>> ctp_data_header_t* hdr;
>> fe_queue_entry_t *qe;
>> dbg("Forwarder", "%s: sending packet from client %hhu: %x, len
>> %hhu\n", __FUNCTION__, client, msg, len);
>> if (!hasState(ROUTING_ON)) {return EOFF;}
>> if (len > call Send.maxPayloadLength[client]()) {return ESIZE;}
>> ......
>>
>> if (clientPtrs[client] == NULL) {
>> dbg("Forwarder", "%s: send failed as client is busy.\n",
>> __FUNCTION__);
>> return EBUSY;
>> }
>> ......
>> }
>>
>>
>> I find in the task sendTask(), when the subsendResult value is not SUCCESS
>> or ESIZE, the phenomenon mentioned above will happen, as below:
>>
>>
>> task void sendTask() {
>>
>> ......
>> subsendResult = call SubSend.send(dest, qe->msg, payloadLen);
>> if (subsendResult == SUCCESS) {
>> // Successfully submitted to the data-link layer.
>> setState(SENDING);
>> dbg("Forwarder", "%s: subsend succeeded with %p.\n",
>> __FUNCTION__, qe->msg);
>> return;
>> }
>> // The packet is too big: truncate it and retry.
>> else if (subsendResult == ESIZE) {
>> dbg("Forwarder", "%s: subsend failed from ESIZE: truncate
>> packet.\n", __FUNCTION__);
>> call Packet.setPayloadLength(qe->msg, call
>> Packet.maxPayloadLength());
>> post sendTask();
>> call CollectionDebug.logEvent(NET_C_FE_SUBSEND_SIZE);
>> }
>> else {
>> dbg("Forwarder", "%s: subsend failed from %i\n", __FUNCTION__,
>> (int)subsendResult);
>> }
>> ......
>> }
>>
>>
>> I find the code didn't deal with when the subsendResult value is not
>> SUCCESS
>> or ESIZE. And when I add "post sendTask();" in the "else" path as below,
>> it is
>> OK and do not appear the above phenomenon (I test about one hour).
>>
>>
>> task void sendTask() {
>>
>> ......
>> subsendResult = call SubSend.send(dest, qe->msg, payloadLen);
>> if (subsendResult == SUCCESS) {
>> // Successfully submitted to the data-link layer.
>> setState(SENDING);
>> dbg("Forwarder", "%s: subsend succeeded with %p.\n",
>> __FUNCTION__, qe->msg);
>> return;
>> }
>> // The packet is too big: truncate it and retry.
>> else if (subsendResult == ESIZE) {
>> dbg("Forwarder", "%s: subsend failed from ESIZE: truncate
>> packet.\n", __FUNCTION__);
>> call Packet.setPayloadLength(qe->msg, call
>> Packet.maxPayloadLength());
>> post sendTask();
>> call CollectionDebug.logEvent(NET_C_FE_SUBSEND_SIZE);
>> }
>> else {
>> post sendTask();
>> dbg("Forwarder", "%s: subsend failed from %i\n", __FUNCTION__,
>> (int)subsendResult);
>> }
>> ......
>> }
>>
>>
>> I think it's may be forget to add the code "post sendTask();", because
>> some reason.
That else condition gets executed if the return value is BUSY or FAIL.
We should not post sendTask() if the return value is BUSY because that
means we have already called Send and we are trying to call another
Send before the sendDone is signaled.
You might be trying to send the packets too fast for the channel
capacity remaining after accounting for what is used by Drip. Can you
try reducing your dissemination rate to once every 10 seconds and see
if you still have the same problem?
- om_p
_______________________________________________
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
