Hi Stephen, I think the stack never duplicates data packets. Do you mean that if an ack packet does not arrive on time, then BLIP will retry, which on a MAC level is a new message, but on the BLIP level it is a duplcate UDPEcho packet?
Zsolt and Krisztian, can you increase the SOFTWAREACK_TIMEOUT to 2000 and see if that improves the situation? (By the way, on our tests we saw only 1-2% duplicate packets on IRIS). Best, Miklos On Wed, Sep 15, 2010 at 5:37 PM, Stephen Dawson-Haggerty <[email protected]> wrote: > I believe this is an issue with the iris radio stack when using > software acks? I remember that its ack timeout was set to be shorter > than the software turnaround time on an epic platform. However, I'm > not an iris expert... > > Steve > > On Mon, Sep 6, 2010 at 10:16 PM, nithin k n <[email protected]> wrote: >> >> hi there >> >> UDPEcho is not behaving well, for eg, while pinging the UDPEcho installed >> motes, the basestation gets too many DUP! packets in reply, >> on an average, the count of DUP! packets is more than actual ping reply >> packets. >> Reason for this? >> >> Regards, >> Nithin >> >> >> _______________________________________________ >> Tinyos-help mailing list >> [email protected] >> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >> > > > > -- > stephen dawson-haggerty > http://cs.berkeley.edu/~stevedh > uc berkeley wireless and embedded systems lab > berkeley, ca 94720 > _______________________________________________ > 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
