Hi Guys! Ok, I found the bug (after a discussion with Zsolt).
In tos/platforms/iris/chips/rf230/RadioConfig.h we set SOFWAREACK_TIMEOUT to 800 (microseconds) if it is undefined. This value should be increased to at least 900 microseconds. In fact, I have increased it to 1000 just to be safe. The fix is committed to the SVN tree (but that will not help since it has a new BLIP which does not work yet for IRIS). Miklos 2010/9/20 Miklos Maroti <mmar...@math.u-szeged.hu>: > Hi Stephen, > > We saw some very strange things, that the software ack was transmitted > quite late after the data message. (Actually we saw 3500 microseconds > between the SDF of the data and ack packets, but the data packet was > quite full, probably very close to the 100 byte limit, so transmitting > the data packet also took some time close to 2-3 microsecs). Anyways, > I have two questions> > > 1) Is there any large block of code of BLIP that disables interrupt > completely? (I am thinking of the serial code) > > 2) Krisztian, can you again calculate the delay between the DATA and > ACK packets and also tell their length? > > Best, > Miklos > > On Mon, Sep 20, 2010 at 12:25 PM, Zsolt Szabó <szabomeis...@gmail.com> wrote: >> Hi all >> >> Found a solution for solving this issue. >> You should either define the RF230_HARDWARE_ACK flag in both the Makefiles >> of UDPEcho and IPBaseStation >> or the SOFTWAREACK_TIMEOUT flag and set it to minimum value of 900. >> >> CFLAGS += -DSOFTWAREACK_TIMEOUT=900 >> >> Although the predefined value for SOFTWAREACK_TIMEOUT in Rf230RadioP is 1000 >> the UDPEcho works properly only with >> the above mentioned adjustments. >> >> Best Regards >> Zsolt >> >> 2010/9/15 Miklos Maroti <mmar...@math.u-szeged.hu> >>> >>> 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 >>> <stev...@eecs.berkeley.edu> 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 <nithin6low...@gmail.com> >>> > 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 >>> >> Tinyos-help@millennium.berkeley.edu >>> >> >>> >> 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 >>> > 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
