Hi, I am using iris motes in the same kind of load. When load is going higher I see this kind of things. I am not sure it is linked but I also have infinite loop into the ctp tree and it never recovers from it. I can see data and beacon datagram from the node from the loop but I never see any beacon from the other nodes. Also the byte next to the 0x70 or 0x71 byte is always 0x00 like if the P bit was never activated.
Should the P bit be activated so that the other node know they have to send a beacon ? They should also respond to broadcasted beacon like this one ? 15:39:05 'r' 1496976736 4955 35 [ 0x61 0x88 0xf1 0x22 0x00 0xff 0xff 0x09 0x00 0x3f 0x70 0x05 0x5a 0x00 0x00 ] 51 255 Do you think that the channel capacity could lead to such behavior (loops in CTP) ? The channel should be so occupied that the mote never sends beacon ? Which algorithm should we use instead of CTP ? Is there an existing one implemented into TinyOS ? Kind regards, Fabrice Dossin On 21 September 2010 11:26, Michiel Konstapel <[email protected]> wrote: > This probably belongs on tinyos-help; I'll CC that list instead. > > > > I think you're just hitting the maximum channel capacity for the radio. 25 > nodes, transmitting every second, means a minimum of 25 packets towards the > sink, every second, which all need to be acked. In addition, if your network > needs multiple hops to the sink, traffic near the sink will also occupy the > channel. It's likely that the channel is simply too busy to send acks, or > they are sent too late and therefore not received. This will in turn make > the problem worse, because all those nodes start retransmitting because > they're not receiving acks, increasing the traffic load even further. CTP > was designed for low data rates, and it doesn't have a mechanism to cope > with this. > > > > In general, you'll note that as you increase the traffic load, you'll reach > a point where the network will run smoothly until a packet is lost, and then > the whole thing melts down due to retransmissions and lost acks. HW acks are > probably faster, so in effect, your maximum traffic load goes up. > > > > HTH, > > Michiel > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Wei Dong > *Sent:* dinsdag 21 september 2010 10:35 > *To:* [email protected] > *Subject:* [Tinyos-devel] CTP broken and ACK delay > > > > Dear all, > > > > I recently used CTP for collecting data from a network of nodes. > > The experiment setup is as follows, > > > > I have used 25 TelosB nodes, and each node periodically transmits three > packets to the sink. > > Each packet transmission uses a different CollectionSender and the packet > size is approximately 100 bytes. > > > > When the period is relatively large, say 5 seconds, the sink can collect > data smoothly. > > However, when one of the packet transmission period decreases to 1 seconds, > CTP is broken, > > and it cannot be recovered when I try to retore the period using the Drip. > > > > I used a sniffer to learn the packet transmission activities, and found > that > > 1) in the normal state, each packet transmission normally follows a > matching ACK > > 2) in the abnormal state, for the most cases, I cannot find matching ACKs > for the data packets. > > > > I think that the radio may be in some state that it cannot ACK others in > time. > > To verify this, I turned on the HW ack mechanism, and the sink can > correctly receive packets when > > one packet period is changed to 1 second. > > > > What's the reasons for missing ACKs in CTP when SW ACK is used? Thanks in > advance. > > > > Wei Dong > > > > _______________________________________________ > Tinyos-help mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
