Re: [Tinyos-help] Drop packets in TinyOS
Hi Eric Up to now, it doesn't work. In fact, when it is supposed the piece of code executes, the mote resets, and I cannot understand it! I'm also debugging the code but I'm missing something because I don't see anything strange. Lets see if I understood your doubts. In relation to who keeps track of what buffers are available or not, I thing that functionality is part of the QueueC component and yours. Yours because you are who mark when a packet has to be dequeued aimed at being transmitted or discarded, and of the QueueC because it points to a free space of memory where you can enqueue a new packet as well as the head of this queue. On the other hand, when you need to enqueue a new packet, you have to return a empty message_t to the MAC by making a call to Pool.get(). Then, you enqueue the packet by calling Queue.enqueue(new_message_t) . Both components, PoolC and QueueC, point to different spaces of memory but they keep track of if you have space to store more packets, the piece of memory where you enqueue/return a message_t... . And when you dequeue a packet, after the event sendDone(msg) is signaled, you make a call to Pool.put(msg) (I'm sure you're aware of this). This make sense for me, but as I said, for now, it doesn't work! Regards David Date: Tue, 27 Nov 2012 16:31:15 -0800 Subject: Re: [Tinyos-help] Drop packets in TinyOS From: cire...@gmail.com To: drod...@outlook.com CC: tinyos-help@millennium.berkeley.edu On Tue, Nov 27, 2012 at 12:16 AM, David Rodenas drod...@outlook.com wrote: Hi Eric In any case, I have a possible answer which is simpler than I thought. I was addressing the problem wrong, thinking that a message that was enqueued, it was really a peace of dynamic/external memory that came (was transmitted) to the receiver node, so it increased the already occupied memory (there is a reason of why a thought this: I also work with Network Simulator 2 - NS2 - and there you use dynamic memory for messages). This is totally wrong with TinyOS, when you receive a data message and enqueue it, you are only copying the whole content to the corresponding memory location (you defined Queue as static memory) and increasing a counter of enqueued messages. Then you can use PoolC to return an empty message_t to the system. Thus, when you make a call to Queue.dequeue(), what this function returns is a pointer to a static portion of memory (of size message_t) as well as decreases the counter of messages enqueued. Therefore, when another message_t is enqueued, this occupies the same portion of memory so the node never run outs of memory because of what I what asking. Am I right? The gist is certainly correct. The devil as always is in the details. I do hand debugging of code like this to make sure that a) the general case works, b) is argueably correct, and then c) examine the corner cases (where can it screw up, and are there assumptions made about how the code works that can be violated). But I didn't write or test this code. so your mileage may vary (YMMV). But I do think you have the gist of how it behaves. The question is who keeps track of what buffers are available and what denotes the buffer being busy. If you dequeue the packet from the queue, does it something else need to be told that this packet is available? Should it get put back into the Pool? eric Thanks again, regards David Date: Mon, 26 Nov 2012 19:51:48 -0800 Subject: Re: [Tinyos-help] Drop packets in TinyOS From: cire...@gmail.com To: drod...@outlook.com CC: tinyos-help@millennium.berkeley.edu Looking at this problem from the queueing mechanism is coming at the problem from the inside out. So it is pretty difficult trying to answer the question you are asking. To do so really requires looking at the data flow (message_t) and buffer flow at various points in packet transmission and reception. The answer to your question depends on what the original caller of the enqueue wants done.And then there is the whole wiring issue and how to pull the whole thing together. Simply dequeuing the message certainly isn't enough because that most likely leads to lost messages. But the whole scheme needs to be worked out in a systemic fashion. And it would be nice if it were documented. It certianly is a hole. Eventually I'll get to it. I certainly understand what you are trying to accomplish. Been there done that.Sorry I don't have a better answer for you. eric On Mon, Nov 26, 2012 at 7:48 AM, David Rodenas drod...@outlook.com wrote: Hi all I would like to know how to discard a message which is stored in a queue (component QueueC of message_t). To better explain this, lets suppose we have a maximum number of retries during we are trying to forward a data message. This is stored in a queue waiting for being transmitted. A failed transmission can occur due to collisions, interferences, etc. So when this maximum number is reached, the data message
Re: [Tinyos-help] Drop packets in TinyOS
On Wed, Nov 28, 2012 at 12:19 AM, David Rodenas drod...@outlook.com wrote: Hi Eric Up to now, it doesn't work. In fact, when it is supposed the piece of code executes, the mote resets, and I cannot understand it! I'm also debugging the code but I'm missing something because I don't see anything strange. If it was me doing this, I'd put a debugger on it. I also write code with explicit Panics and the code checks itself. I know that doesn't help your current situation. But standing on the outside of a black box trying to figure out why the beasty doesn't work doesn't in my experience work. You have to open the box and find out what is going on. Lets see if I understood your doubts. In relation to who keeps track of what buffers are available or not, I thing that functionality is part of the QueueC component and yours. This is too hard to do via words. The language barrier doesn't help but you are doing very well all things considered. Yours because you are who mark when a packet has to be dequeued aimed at being transmitted or discarded, That sounds right. and of the QueueC because it points to a free space of memory where you can enqueue a new packet as well as the head of this queue. I don't understand that. Not sure what you are trying to say. On the other hand, when you need to enqueue a new packet, you have to return a empty message_t to the MAC by making a call to Pool.get(). Then, you enqueue the packet by calling Queue.enqueue(new_message_t) . This is part of the confusion doing this with words. What MAC? When is the message/packet being returned to the MAC? Are we receiving or transmitting?Who are you enqueueing the packet to via Queue.enqueue. The connections between the different implementations (like Queue) is what the wiring specification defines. Both components, PoolC and QueueC, point to different spaces of memory but they keep track of if you have space to store more packets, the piece of memory where you enqueue/return a message_t... . And when you dequeue a packet, after the event sendDone(msg) is signaled, you make a call to Pool.put(msg) (I'm sure you're aware of this). This make sense for me, but as I said, for now, it doesn't work! I think you are figuring it out.But without getting in and seeing exactly what it is doing all you can do is say it doesn't work. And I'm not going to be able to use my majik crystal ball to look inside your remote mote and see any better. Sorry it that sounds snide. Not meant to be. eric Regards David -- Date: Tue, 27 Nov 2012 16:31:15 -0800 Subject: Re: [Tinyos-help] Drop packets in TinyOS From: cire...@gmail.com To: drod...@outlook.com CC: tinyos-help@millennium.berkeley.edu On Tue, Nov 27, 2012 at 12:16 AM, David Rodenas drod...@outlook.comwrote: Hi Eric In any case, I have a possible answer which is simpler than I thought. I was addressing the problem wrong, thinking that a message that was enqueued, it was really a peace of dynamic/external memory that came (was transmitted) to the receiver node, so it increased the already occupied memory (there is a reason of why a thought this: I also work with Network Simulator 2 - NS2 - and there you use dynamic memory for messages). This is totally wrong with TinyOS, when you receive a data message and enqueue it, you are only copying the whole content to the corresponding memory location (you defined Queue as static memory) and increasing a counter of enqueued messages. Then you can use PoolC to return an empty message_t to the system. Thus, when you make a call to Queue.dequeue(), what this function returns is a pointer to a static portion of memory (of size message_t) as well as decreases the counter of messages enqueued. Therefore, when another message_t is enqueued, this occupies the same portion of memory so the node never run outs of memory because of what I what asking. Am I right? The gist is certainly correct. The devil as always is in the details. I do hand debugging of code like this to make sure that a) the general case works, b) is argueably correct, and then c) examine the corner cases (where can it screw up, and are there assumptions made about how the code works that can be violated). But I didn't write or test this code. so your mileage may vary (YMMV). But I do think you have the gist of how it behaves. The question is who keeps track of what buffers are available and what denotes the buffer being busy. If you dequeue the packet from the queue, does it something else need to be told that this packet is available? Should it get put back into the Pool? eric Thanks again, regards David -- Date: Mon, 26 Nov 2012 19:51:48 -0800 Subject: Re: [Tinyos-help] Drop packets in TinyOS From: cire...@gmail.com To: drod...@outlook.com CC: tinyos-help@millennium.berkeley.edu Looking at this problem
Re: [Tinyos-help] Drop packets in TinyOS
Hi Eric
thanks for your answer. In fact, I thought the same. Although there is
something you pointed out that it just what I need: The answer to your
question depends on what the original caller of the enqueue wants done. [...]
Simply dequeuing the message certainly isn't enough because that most likely
leads to lost messages. Certeanly, what I need is that, if a message has to be
dropped, then it counts as a lost message. So what I don't want to is being
dequeuing messages and at the end, run out of memory because I did not manage
it correctly handling these dequeued messages.
In any case, I have a possible answer which is simpler than I thought. I was
addressing the problem wrong, thinking that a message that was enqueued, it was
really a peace of dynamic/external memory that came (was transmitted) to the
receiver node, so it increased the already occupied memory (there is a reason
of why a thought this: I also work with Network Simulator 2 - NS2 - and there
you use dynamic memory for messages). This is totally wrong with TinyOS, when
you receive a data message and enqueue it, you are only copying the whole
content to the corresponding memory location (you defined Queue as static
memory) and increasing a counter of enqueued messages. Then you can use PoolC
to return an empty message_t to the system. Thus, when you make a call to
Queue.dequeue(), what this function returns is a pointer to a static portion of
memory (of size message_t) as well as decreases the counter of messages
enqueued. Therefore, when another message_t is enqueued, this occupies the same
portion of memory so the node never run outs of memory because of what I what
asking.
Am I right?
Thanks again, regards
David
Date: Mon, 26 Nov 2012 19:51:48 -0800
Subject: Re: [Tinyos-help] Drop packets in TinyOS
From: cire...@gmail.com
To: drod...@outlook.com
CC: tinyos-help@millennium.berkeley.edu
Looking at this problem from the queueing mechanism is coming at the problem
from the inside out.
So it is pretty difficult trying to answer the question you are asking.
To do so really requires looking at the data flow (message_t) and buffer flow
at various points in packet transmission and reception.
The answer to your question depends on what the original caller of the enqueue
wants done.And then there is the whole wiring issue and how to pull the
whole thing together.
Simply dequeuing the message certainly isn't enough because that most likely
leads to lost messages. But the whole scheme needs to be worked out in a
systemic fashion. And it would be nice if it were documented. It certianly
is a hole. Eventually I'll get to it.
I certainly understand what you are trying to accomplish. Been there done
that.Sorry I don't have a better answer for you.
eric
On Mon, Nov 26, 2012 at 7:48 AM, David Rodenas drod...@outlook.com wrote:
Hi all
I would like to know how to discard a message which is stored in a queue
(component QueueC of message_t). To better explain this, lets suppose we have a
maximum number of retries during we are trying to forward a data message. This
is stored in a queue waiting for being transmitted. A failed transmission can
occur due to collisions, interferences, etc. So when this maximum number is
reached, the data message should be discarded, making this same procedure with
the following message (head of the queue). Here there is a simple code of what
I'm asking:
maximum_retries = 3;num_retries = 0;
if (num_retries maximum_retries){message_t * drop_msg = call
Queue.dequeue();drop(drop_msg);
}
The point is that I'm not sure if just dequeuing the message_t is enough. This
message occupies a piece of memory space and this has to be freed. Am I right?
Should I use the function free as in any C-based language when dynamic memory
allocation is used?
Thanks
David
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
--
Eric B. Decker
Senior (over 50 :-) Researcher
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Drop packets in TinyOS
On Tue, Nov 27, 2012 at 12:16 AM, David Rodenas drod...@outlook.com wrote:
Hi Eric
In any case, I have a possible answer which is simpler than I thought. I
was addressing the problem wrong, thinking that a message that was
enqueued, it was really a peace of dynamic/external memory that came (was
transmitted) to the receiver node, so it increased the already occupied
memory (there is a reason of why a thought this: I also work with Network
Simulator 2 - NS2 - and there you use dynamic memory for messages). This is
totally wrong with TinyOS, when you receive a data message and enqueue it,
you are only copying the whole content to the corresponding memory location
(you defined Queue as static memory) and increasing a counter of enqueued
messages.
Then you can use PoolC to return an empty message_t to the system. Thus,
when you make a call to Queue.dequeue(), what this function returns is a
pointer to a static portion of memory (of size message_t) as well as
decreases the counter of messages enqueued. Therefore, when another
message_t is enqueued, this occupies the same portion of memory so the node
never run outs of memory because of what I what asking.
Am I right?
The gist is certainly correct. The devil as always is in the details.
I do hand debugging of code like this to make sure that a) the general case
works, b) is argueably correct, and then c) examine the corner cases (where
can it screw up, and are there assumptions made about how the code works
that can be violated). But I didn't write or test this code.
so your mileage may vary (YMMV).
But I do think you have the gist of how it behaves.
The question is who keeps track of what buffers are available and what
denotes the buffer being busy. If you dequeue the packet from the
queue, does it something else need to be told that this packet is
available? Should it get put back into the Pool?
eric
Thanks again, regards
David
--
Date: Mon, 26 Nov 2012 19:51:48 -0800
Subject: Re: [Tinyos-help] Drop packets in TinyOS
From: cire...@gmail.com
To: drod...@outlook.com
CC: tinyos-help@millennium.berkeley.edu
Looking at this problem from the queueing mechanism is coming at the
problem from the inside out.
So it is pretty difficult trying to answer the question you are asking.
To do so really requires looking at the data flow (message_t) and buffer
flow at various points in packet transmission and reception.
The answer to your question depends on what the original caller of the
enqueue wants done.And then there is the whole wiring issue and how to
pull the whole thing together.
Simply dequeuing the message certainly isn't enough because that most
likely leads to lost messages. But the whole scheme needs to be worked out
in a systemic fashion. And it would be nice if it were documented. It
certianly is a hole. Eventually I'll get to it.
I certainly understand what you are trying to accomplish. Been there done
that.Sorry I don't have a better answer for you.
eric
On Mon, Nov 26, 2012 at 7:48 AM, David Rodenas drod...@outlook.comwrote:
Hi all
I would like to know how to discard a message which is stored in a queue
(component QueueC of message_t). To better explain this, lets suppose we
have a maximum number of retries during we are trying to forward a data
message. This is stored in a queue waiting for being transmitted. A failed
transmission can occur due to collisions, interferences, etc. So when this
maximum number is reached, the data message should be discarded, making
this same procedure with the following message (head of the queue). Here
there is a simple code of what I'm asking:
maximum_retries = 3;
num_retries = 0;
if (num_retries maximum_retries)
{
message_t * drop_msg = call Queue.dequeue();
drop(drop_msg);
}
The point is that I'm not sure if just dequeuing the message_t is enough.
This message occupies a piece of memory space and this has to be freed. Am
I right? Should I use the function free as in any C-based language when
dynamic memory allocation is used?
Thanks
David
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
--
Eric B. Decker
Senior (over 50 :-) Researcher
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
--
Eric B. Decker
Senior (over 50 :-) Researcher
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Drop packets in TinyOS
Hi all
I would like to know how to discard a message which is stored in a queue
(component QueueC of message_t). To better explain this, lets suppose we have a
maximum number of retries during we are trying to forward a data message. This
is stored in a queue waiting for being transmitted. A failed transmission can
occur due to collisions, interferences, etc. So when this maximum number is
reached, the data message should be discarded, making this same procedure with
the following message (head of the queue). Here there is a simple code of what
I'm asking:
maximum_retries = 3;num_retries = 0;
if (num_retries maximum_retries){message_t * drop_msg = call
Queue.dequeue();drop(drop_msg);}
The point is that I'm not sure if just dequeuing the message_t is enough. This
message occupies a piece of memory space and this has to be freed. Am I right?
Should I use the function free as in any C-based language when dynamic memory
allocation is used?
Thanks
David ___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Drop packets in TinyOS
Looking at this problem from the queueing mechanism is coming at the
problem from the inside out.
So it is pretty difficult trying to answer the question you are asking.
To do so really requires looking at the data flow (message_t) and buffer
flow at various points in packet transmission and reception.
The answer to your question depends on what the original caller of the
enqueue wants done.And then there is the whole wiring issue and how to
pull the whole thing together.
Simply dequeuing the message certainly isn't enough because that most
likely leads to lost messages. But the whole scheme needs to be worked out
in a systemic fashion. And it would be nice if it were documented. It
certianly is a hole. Eventually I'll get to it.
I certainly understand what you are trying to accomplish. Been there done
that.Sorry I don't have a better answer for you.
eric
On Mon, Nov 26, 2012 at 7:48 AM, David Rodenas drod...@outlook.com wrote:
Hi all
I would like to know how to discard a message which is stored in a queue
(component QueueC of message_t). To better explain this, lets suppose we
have a maximum number of retries during we are trying to forward a data
message. This is stored in a queue waiting for being transmitted. A failed
transmission can occur due to collisions, interferences, etc. So when this
maximum number is reached, the data message should be discarded, making
this same procedure with the following message (head of the queue). Here
there is a simple code of what I'm asking:
maximum_retries = 3;
num_retries = 0;
if (num_retries maximum_retries)
{
message_t * drop_msg = call Queue.dequeue();
drop(drop_msg);
}
The point is that I'm not sure if just dequeuing the message_t is enough.
This message occupies a piece of memory space and this has to be freed. Am
I right? Should I use the function free as in any C-based language when
dynamic memory allocation is used?
Thanks
David
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
--
Eric B. Decker
Senior (over 50 :-) Researcher
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
