Re: [Tinyos-help] Never get an ACK on Iris motes
Hi Miklos,
you were right. I did not put the messages back into the pool in the case of
failure. I corrected this in my example application and now I am no longer able
to reproduce the error I had before. I wonder though why this is the case since
as I said before I never had a run in which a send() or sendDone() gave me an
error, so all packets from the pool should have been returned to the pool after
sending. Does this mean that I have to write code like this to make sure my
application works properly?:
function {
if(whatever) {
do something with the message_t from pool;
return message_t to pool;
return from function;
}
else {
do something else with the message_t from pool;
return message_t to pool;
return from function;
}
return message_t to pool;
return from function;
}
In my eyes the code after the if-else statement is unnecessary since I will
never get there. But in my example application the code that was never reached
in a test run (even though it was reachable in contrast to the example above)
nevertheless changed my programs behavior. In my real program I do still get
the described error and I do not know where to search for leaking packets or
other errors anymore.
Thanks for your advice
David
Am 20.06.2011 um 15:27 schrieb Miklos Maroti:
Hi David,
On Mon, Jun 20, 2011 at 12:39 PM, David Piotrowski tin...@zeroflag.eu wrote:
Hi Miklos,
I do not get failures, send returns just fine. I am also releasing the
packets back to the pool after sondDone occurs.
No, you do NOT put back the message after a sendDone(FAIL) even or a
send command which fails.
The packets from the pool are only manipulated after I get them from the
pool and before I release them to the pool again, so I think even if they
get corrupted in the pool they should be properly setup again before sending
them. I am not using Packet.clear though. I'll try that and see whether it
has any influence on my results.
You should call Packet.clear(). I suppose, that the MessagePool
maintains a linked list of entries and stores pointers and that
corrupts the internal layout, so you have to call Packet.clear() for
each message.
Best,
Miklos
Thanks for your input.
David
Am 19.06.2011 um 23:45 schrieb Miklos Maroti:
Hi David,
Do you see any failures? (send fails or sendDone fails?) If any of
those occur, then you have to put the message back to the pool.
Another thing you should do: call Packet.clear before you set up the
data in the message. The values in the pool can be corrupted. I think
this is the source of your problems.
Best,
Miklos
On Sun, Jun 19, 2011 at 11:33 PM, David Piotrowski tin...@zeroflag.eu
wrote:
Hello again,
I did some more investigations on the ACK error I described in my previous
mail. It seems like I had quite the same error about a year ago but since
then I used tossim quite a lot and the error did not show up there.
I have written a small example application that shows the error I have.
The application has a fixed message_t variable and a pool from which it
gets another message_t. It then sends the fixed message_t and the
message_t from the pool alternately over and over again. Upon reception
the receiving node lights the received message on its LED. The nodes print
some debugging information out on the screen showing which kind of
message_t they are actually sending and if it is acknowledged.
Depending on the size of the pool used I get different behavior when it
comes to acknowledgements. For me the configuration of the program
appended yields no ack for packets that come from the pool but the packets
not coming from the pool all get acknowledgements. Other pool sizes yield
other results. In several (maybe all?) configurations the first two
packets never get acknowledged independent of whether they come from the
pool or not. Another thing to notice is that although the packets are not
acknowledged, they have been properly received, which is signaled by the
blinking LEDs. In some configurations the behaviour of ACKs changes
between resets of the node.
I am really searching for some advice on this. The actual program I am
working on is using at least two pools, which I suspect are the reason why
I never get an ack there although all the messages sent are received and
everything is working flawless in tossim.
Thanks, David.
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Never get an ACK on Iris motes
Hi David!
The code after the else is completely unnecessary. You code was this.
Notice, that in the if(err==FAIL) case you return, but you do not put
back the message in the pool. Good that it works for you now.
Best,
Miklos
event void AMSend.sendDone(message_t* msg, error_t err) {
if(err==FAIL) {
printf(sendDone() returned FAIL...\n);
printfflush();
return;
}
if(call PacketAcknowledgements.wasAcked(msg)==FALSE) {
if(msg==testMessage) { // This is an unbuffered packet
printf(Unbuffered packet was not
acknowledged...\n);
printfflush();
}
else { // This is a packet from the queue
printf(Buffered packet was not
acknowledged...\n);
printfflush();
call testPool.put(msg);
}
}
else {
if(msg==testMessage) { // This is an unbuffered packet
printf(Unbuffered packet was
acknowledged...\n);
printfflush();
}
else { // This is a packet from the queue
printf(Buffered packet was acknowledged...\n);
printfflush();
call testPool.put(msg);
}
}
}
On Thu, Jun 23, 2011 at 8:10 PM, David Piotrowski tin...@zeroflag.eu wrote:
Hi Miklos,
you were right. I did not put the messages back into the pool in the case of
failure. I corrected this in my example application and now I am no longer
able to reproduce the error I had before. I wonder though why this is the
case since as I said before I never had a run in which a send() or sendDone()
gave me an error, so all packets from the pool should have been returned to
the pool after sending. Does this mean that I have to write code like this to
make sure my application works properly?:
function {
if(whatever) {
do something with the message_t from pool;
return message_t to pool;
return from function;
}
else {
do something else with the message_t from pool;
return message_t to pool;
return from function;
}
return message_t to pool;
return from function;
}
In my eyes the code after the if-else statement is unnecessary since I will
never get there. But in my example application the code that was never
reached in a test run (even though it was reachable in contrast to the
example above) nevertheless changed my programs behavior. In my real program
I do still get the described error and I do not know where to search for
leaking packets or other errors anymore.
Thanks for your advice
David
Am 20.06.2011 um 15:27 schrieb Miklos Maroti:
Hi David,
On Mon, Jun 20, 2011 at 12:39 PM, David Piotrowski tin...@zeroflag.eu
wrote:
Hi Miklos,
I do not get failures, send returns just fine. I am also releasing the
packets back to the pool after sondDone occurs.
No, you do NOT put back the message after a sendDone(FAIL) even or a
send command which fails.
The packets from the pool are only manipulated after I get them from the
pool and before I release them to the pool again, so I think even if they
get corrupted in the pool they should be properly setup again before
sending them. I am not using Packet.clear though. I'll try that and see
whether it has any influence on my results.
You should call Packet.clear(). I suppose, that the MessagePool
maintains a linked list of entries and stores pointers and that
corrupts the internal layout, so you have to call Packet.clear() for
each message.
Best,
Miklos
Thanks for your input.
David
Am 19.06.2011 um 23:45 schrieb Miklos Maroti:
Hi David,
Do you see any failures? (send fails or sendDone fails?) If any of
those occur, then you have to put the message back to the pool.
Another thing you should do: call Packet.clear before you set up the
data in the message. The values in the pool can be corrupted. I think
this is the source of your problems.
Best,
Miklos
On Sun, Jun 19, 2011 at 11:33 PM, David Piotrowski tin...@zeroflag.eu
wrote:
Hello again,
I did some more investigations on the ACK error I described in my
previous mail. It seems like I had quite the same error about a year ago
but since then I used tossim quite a lot and the error did not show up
there.
I have written a small example application that shows the error I have.
The application has a fixed message_t variable and a pool
Re: [Tinyos-help] Never get an ACK on Iris motes
Hi Miklos, I do not get failures, send returns just fine. I am also releasing the packets back to the pool after sondDone occurs. The packets from the pool are only manipulated after I get them from the pool and before I release them to the pool again, so I think even if they get corrupted in the pool they should be properly setup again before sending them. I am not using Packet.clear though. I'll try that and see whether it has any influence on my results. Thanks for your input. David Am 19.06.2011 um 23:45 schrieb Miklos Maroti: Hi David, Do you see any failures? (send fails or sendDone fails?) If any of those occur, then you have to put the message back to the pool. Another thing you should do: call Packet.clear before you set up the data in the message. The values in the pool can be corrupted. I think this is the source of your problems. Best, Miklos On Sun, Jun 19, 2011 at 11:33 PM, David Piotrowski tin...@zeroflag.eu wrote: Hello again, I did some more investigations on the ACK error I described in my previous mail. It seems like I had quite the same error about a year ago but since then I used tossim quite a lot and the error did not show up there. I have written a small example application that shows the error I have. The application has a fixed message_t variable and a pool from which it gets another message_t. It then sends the fixed message_t and the message_t from the pool alternately over and over again. Upon reception the receiving node lights the received message on its LED. The nodes print some debugging information out on the screen showing which kind of message_t they are actually sending and if it is acknowledged. Depending on the size of the pool used I get different behavior when it comes to acknowledgements. For me the configuration of the program appended yields no ack for packets that come from the pool but the packets not coming from the pool all get acknowledgements. Other pool sizes yield other results. In several (maybe all?) configurations the first two packets never get acknowledged independent of whether they come from the pool or not. Another thing to notice is that although the packets are not acknowledged, they have been properly received, which is signaled by the blinking LEDs. In some configurations the behaviour of ACKs changes between resets of the node. I am really searching for some advice on this. The actual program I am working on is using at least two pools, which I suspect are the reason why I never get an ack there although all the messages sent are received and everything is working flawless in tossim. Thanks, David. ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Never get an ACK on Iris motes
I forgot to mention that if you want to try the test application out you just take two nodes and install the application assigning the nodes the addresses 1 and 2. They will figure out where to send the messages on their own then. David Am 19.06.2011 um 23:33 schrieb David Piotrowski: Hello again, I did some more investigations on the ACK error I described in my previous mail. It seems like I had quite the same error about a year ago but since then I used tossim quite a lot and the error did not show up there. I have written a small example application that shows the error I have. The application has a fixed message_t variable and a pool from which it gets another message_t. It then sends the fixed message_t and the message_t from the pool alternately over and over again. Upon reception the receiving node lights the received message on its LED. The nodes print some debugging information out on the screen showing which kind of message_t they are actually sending and if it is acknowledged. Depending on the size of the pool used I get different behavior when it comes to acknowledgements. For me the configuration of the program appended yields no ack for packets that come from the pool but the packets not coming from the pool all get acknowledgements. Other pool sizes yield other results. In several (maybe all?) configurations the first two packets never get acknowledged independent of whether they come from the pool or not. Another thing to notice is that although the packets are not acknowledged, they have been properly received, which is signaled by the blinking LEDs. In some configurations the behaviour of ACKs changes between resets of the node. I am really searching for some advice on this. The actual program I am working on is using at least two pools, which I suspect are the reason why I never get an ack there although all the messages sent are received and everything is working flawless in tossim. Thanks, David. MakefilepoolTestAppC.ncpoolTestC.nc ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Never get an ACK on Iris motes
Hi David, On Mon, Jun 20, 2011 at 12:39 PM, David Piotrowski tin...@zeroflag.eu wrote: Hi Miklos, I do not get failures, send returns just fine. I am also releasing the packets back to the pool after sondDone occurs. No, you do NOT put back the message after a sendDone(FAIL) even or a send command which fails. The packets from the pool are only manipulated after I get them from the pool and before I release them to the pool again, so I think even if they get corrupted in the pool they should be properly setup again before sending them. I am not using Packet.clear though. I'll try that and see whether it has any influence on my results. You should call Packet.clear(). I suppose, that the MessagePool maintains a linked list of entries and stores pointers and that corrupts the internal layout, so you have to call Packet.clear() for each message. Best, Miklos Thanks for your input. David Am 19.06.2011 um 23:45 schrieb Miklos Maroti: Hi David, Do you see any failures? (send fails or sendDone fails?) If any of those occur, then you have to put the message back to the pool. Another thing you should do: call Packet.clear before you set up the data in the message. The values in the pool can be corrupted. I think this is the source of your problems. Best, Miklos On Sun, Jun 19, 2011 at 11:33 PM, David Piotrowski tin...@zeroflag.eu wrote: Hello again, I did some more investigations on the ACK error I described in my previous mail. It seems like I had quite the same error about a year ago but since then I used tossim quite a lot and the error did not show up there. I have written a small example application that shows the error I have. The application has a fixed message_t variable and a pool from which it gets another message_t. It then sends the fixed message_t and the message_t from the pool alternately over and over again. Upon reception the receiving node lights the received message on its LED. The nodes print some debugging information out on the screen showing which kind of message_t they are actually sending and if it is acknowledged. Depending on the size of the pool used I get different behavior when it comes to acknowledgements. For me the configuration of the program appended yields no ack for packets that come from the pool but the packets not coming from the pool all get acknowledgements. Other pool sizes yield other results. In several (maybe all?) configurations the first two packets never get acknowledged independent of whether they come from the pool or not. Another thing to notice is that although the packets are not acknowledged, they have been properly received, which is signaled by the blinking LEDs. In some configurations the behaviour of ACKs changes between resets of the node. I am really searching for some advice on this. The actual program I am working on is using at least two pools, which I suspect are the reason why I never get an ack there although all the messages sent are received and everything is working flawless in tossim. Thanks, David. ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Never get an ACK on Iris motes
Hello again, I did some more investigations on the ACK error I described in my previous mail. It seems like I had quite the same error about a year ago but since then I used tossim quite a lot and the error did not show up there. I have written a small example application that shows the error I have. The application has a fixed message_t variable and a pool from which it gets another message_t. It then sends the fixed message_t and the message_t from the pool alternately over and over again. Upon reception the receiving node lights the received message on its LED. The nodes print some debugging information out on the screen showing which kind of message_t they are actually sending and if it is acknowledged. Depending on the size of the pool used I get different behavior when it comes to acknowledgements. For me the configuration of the program appended yields no ack for packets that come from the pool but the packets not coming from the pool all get acknowledgements. Other pool sizes yield other results. In several (maybe all?) configurations the first two packets never get acknowledged independent of whether they come from the pool or not. Another thing to notice is that although the packets are not acknowledged, they have been properly received, which is signaled by the blinking LEDs. In some configurations the behaviour of ACKs changes between resets of the node. I am really searching for some advice on this. The actual program I am working on is using at least two pools, which I suspect are the reason why I never get an ack there although all the messages sent are received and everything is working flawless in tossim. Thanks, David. Makefile Description: Binary data poolTestAppC.nc Description: Binary data poolTestC.nc Description: Binary data ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Never get an ACK on Iris motes
Hi David, Do you see any failures? (send fails or sendDone fails?) If any of those occur, then you have to put the message back to the pool. Another thing you should do: call Packet.clear before you set up the data in the message. The values in the pool can be corrupted. I think this is the source of your problems. Best, Miklos On Sun, Jun 19, 2011 at 11:33 PM, David Piotrowski tin...@zeroflag.eu wrote: Hello again, I did some more investigations on the ACK error I described in my previous mail. It seems like I had quite the same error about a year ago but since then I used tossim quite a lot and the error did not show up there. I have written a small example application that shows the error I have. The application has a fixed message_t variable and a pool from which it gets another message_t. It then sends the fixed message_t and the message_t from the pool alternately over and over again. Upon reception the receiving node lights the received message on its LED. The nodes print some debugging information out on the screen showing which kind of message_t they are actually sending and if it is acknowledged. Depending on the size of the pool used I get different behavior when it comes to acknowledgements. For me the configuration of the program appended yields no ack for packets that come from the pool but the packets not coming from the pool all get acknowledgements. Other pool sizes yield other results. In several (maybe all?) configurations the first two packets never get acknowledged independent of whether they come from the pool or not. Another thing to notice is that although the packets are not acknowledged, they have been properly received, which is signaled by the blinking LEDs. In some configurations the behaviour of ACKs changes between resets of the node. I am really searching for some advice on this. The actual program I am working on is using at least two pools, which I suspect are the reason why I never get an ack there although all the messages sent are received and everything is working flawless in tossim. Thanks, David. ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
