Dear All. Sorry for the late answer, but we had to make some tests before answer to your questions. You can look at my comment below.
On Fri, Jun 18, 2010 at 21:54, Miklos Maroti <mmar...@math.u-szeged.hu> wrote: > Hi Stefano, > >>> Do you know the source of your packet loss? >> >> Yes, we believe to know the source of the problem. It should be >> related to channel access. In fact, we made some experiment with to >> identify the source of the problem. The simplest configuration which >> shown the packet loss was the following. A network composed by 4 node, >> a sink (connected to the PC), a timer node, and two leaves nodes. The >> timer node was sending a beacon packet once every second, while the >> leaves nodes when received the beacon packet they answered by sending >> a packet to the sink. The result of the experiment shown a packet loss >> of 50% of the packet sent by the leaves node to the sink, with an >> equal distribution between the leaves. > > That is very strange. It should have practically no packet loss (at > reasonable traffic). Can you post your code? I will try to provide a sample which produce the same packet loss behavior. Unfortunately, I cannot send you the actual source code because I think it is more complex compared to what I described to you so I don't think that it will be easy to use for discovering the issue. > >>> Did you try to fiddle with the software collision avoidance algorithm? >> >> Which "software collision avoidance algorithm" are you referring to? >> How can I fiddle with it? > > Read the chips/rf2xx/README and chips/rf2xx/rf230/README files. I was > referring to the slotted collision avoidance algorithm, which you can > enable by defining SLOTTED_MAC in your makefile. Also you can change > the random backoff periods for the default CA algorithm. > >> As I mentioned above, please consider that in our scenario we do not >> need the ACK. > > Just because you do not need it, you can still enable it. Do you > observe the same behavior with the standard driver which does not do > hardware acks? We performed several tests, but the resulting packet loss was always the same. In particular, we tried the scenario described at the beginning of the e-mail, where the timer node was transmitting every 512ms, divided in 16 slots of 32ms. The timer node sent the packet at the slot 4 (128ms), while the leaves node replied at the slot 7 (224ms)to the sink. We tried all combination of the following IRIS configuration: HARDWARE_ACK = enabled / disabled SLOTTED_MAC = enabled / disabled TASKLET_IS_TASK = enabled / disabled It's worth to notice that without TASKLET_IS_TASK (with a network configuration different from the one that I described) our software freeze from time to times. > > Miklos > _______________________________________________ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
