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
