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ó <[email protected]> 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 <[email protected]> >> >> 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
