---------- Forwarded message ---------- From: nithin k n <[email protected]> Date: Thu, Oct 7, 2010 at 6:48 PM Subject: Fwd: [Tinyos-help] Fwd: UDPEcho in iris To: Miklos Maroti <[email protected]>
hi Miklos, the pinging to iris gets stuck every time after 165 pings (on an average) . what may be the reason ? regards, Nithin ---------- Forwarded message ---------- From: nithin k n <[email protected]> Date: Thu, Oct 7, 2010 at 6:47 PM Subject: Fwd: [Tinyos-help] Fwd: UDPEcho in iris To: Miklos Maroti <[email protected]> the pinging to iris stops every 165 (on an average) . what may be the reason ? ---------- Forwarded message ---------- From: Miklos Maroti <[email protected]> Date: 2010/9/21 Subject: Re: [Tinyos-help] Fwd: UDPEcho in iris To: Zsolt Szabó <[email protected]> Cc: Stephen Dawson-Haggerty <[email protected]>, nithin k n < [email protected]>, [email protected], Veress Krisztián <[email protected]>, Bíró András <[email protected]> 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 <[email protected]>: > 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 <http://cs.berkeley.edu/%7Estevedh> >>> > 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
