i forgot to mention that after the pinging stops on the 165th ping, ,,, if we reset the BaseStation iris mote manually, everything works well till next 165th ping ..
Nithin K N On Sat, Oct 9, 2010 at 10:05 AM, nithin k n <[email protected]> wrote: > i did set SOFTWAREACK_TIMEOUT to 900 in both makefiles of UDPEcho and IPB > ... i guess thats it was the solution.. and in the other way i am little > doubted of how and where to define RF230HARDWAREACK. > > I ll see through that and will reply, > > Regards, > Nithin K N > > > On Fri, Oct 8, 2010 at 6:59 PM, Miklos Maroti <[email protected]>wrote: > >> Hi! >> >> You had to define RF230HARDWAREACK or set SOFTWAREACK_TIMEOUT to 900. >> Does both of these solutions result in the ping stopping? >> >> Miklos >> >> On Fri, Oct 8, 2010 at 3:07 PM, nithin k n <[email protected]> >> wrote: >> > Hello all, >> > The solution for getting rid of DUP! packets on every ping was >> like >> > to define RF230HARDWAREACK_TIMEOUT or SOFTWAREACK_TIMEOUT to 900 in >> > makefiles of both UDPEcho and IPBaseStation , and increase >> > SOFTWAREACK_TIMEOUT to 900(atleast) in >> > /opt/tinyos-2.x/tos/platforms/iris/chips/rf230/RadioConfig.h .... >> > this in turn led to a problem where the pinging to iris stops everytime >> at >> > the 165th ping(on an average) ... i deduce the problem is like memory >> leak >> > kind of is happening in BaseStation, .. any solutions please ? >> > >> > Regards, >> > Nithin K N >> > >> > On Thu, Oct 7, 2010 at 7:36 PM, Miklos Maroti <[email protected] >> > >> > wrote: >> >> >> >> I do not know. I will get someone to look at this. Miklos >> >> >> >> On Thu, Oct 7, 2010 at 3:18 PM, nithin k n <[email protected]> >> >> wrote: >> >> > 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
