Nithin
---------------------------- Original Message ---------------------------- Subject: Re: [Tinyos-help] iris ip base station problem From: "PIETRO GONIZZI" <pietro.goni...@studenti.unipr.it> Date: Mon, December 20, 2010 19:36 To: "Nithin K N" <nit...@ece.iisc.ernet.in> -------------------------------------------------------------------------- How did you do for telosb? Actually telosb does not use the rf230 chip, so you simply changed the SOFTWARE_ACK_TIMEOUT in this case? Concerning the ping problem after 165 pings, I am not having it, but I have not tried so much. pietro 2010/12/20 Nithin K N <nit...@ece.iisc.ernet.in> > with great sigh , i am happy to get a responder after long wait. > as per your question , > yes, > TelosB motes work absolutely well. > > but i am still seeing for solving this problem in iris > Nithin > > > Hi Nithin, > > > > I'm having the same problem in these weeks. > > Also with the increased timeout I still receive duplicated packets. Did > > you > > solve the problem? > > What if you use different platforms instead of iris? > > > > 2010/12/20 Nithin K N <nit...@ece.iisc.ernet.in> > > > >> Hello all, > >> in iris motes > >> 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 <mmar...@math.u-szeged.hu > > > >> 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 <nithin6low...@gmail.com> > >> 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 <nithin6low...@gmail.com> > >> > Date: Thu, Oct 7, 2010 at 6:47 PM > >> > Subject: Fwd: [Tinyos-help] Fwd: UDPEcho in iris > >> > To: Miklos Maroti <mmar...@gmail.com> > >> > > >> > > >> > the pinging to iris stops every 165 (on an average) . what may be > >> the reason > >> > ? > >> > > >> > ---------- Forwarded message ---------- > >> > From: Miklos Maroti <mmar...@math.u-szeged.hu> > >> > Date: 2010/9/21 > >> > Subject: Re: [Tinyos-help] Fwd: UDPEcho in iris > >> > To: Zsolt Szabó <szabomeis...@gmail.com> > >> > Cc: Stephen Dawson-Haggerty <stev...@eecs.berkeley.edu>, nithin k > n > >> > <nithin6low...@gmail.com>, tinyos-help@millennium.berkeley.edu, > >> Veress > >> > Krisztián <veresskriszt...@gmail.com>, Bíró András < > >> bband...@gmail.com> > >> > > >> > > >> > 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<http://cs.berkeley.edu/%7Estevedh> > <http://cs.berkeley.edu/%7Estevedh> > >> >>>> > 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 > >> >>>> > > >> >>> > >> >>> > >> >> > >> > > >> > > >> > > >> > >> > >> > >> Nithin > >> > >> > >> > >> -- > >> This message has been scanned for viruses and > >> dangerous content by MailScanner, and is > >> believed to be clean. > >> > >> _______________________________________________ > >> Tinyos-help mailing list > >> Tinyos-help@millennium.berkeley.edu > >> > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > >> > > > > -- > > This message has been scanned for viruses and > > dangerous content by MailScanner, and is > > believed to be clean. > > > > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.How did you do for telosb?
Actually telosb does not use the rf230 chip, so you simply changed the SOFTWARE_ACK_TIMEOUT in this case?
Concerning the ping problem after 165 pings, I am not having it, but I have not tried so much.
pietro
2010/12/20 Nithin K N <nit...@ece.iisc.ernet.in>
with great sigh , i am happy to get a responder after long wait.
as per your question ,
yes,
TelosB motes work absolutely well.
but i am still seeing for solving this problem in iris
Nithin
>> >>>> > http://cs.berkeley.edu/~stevedh<http://cs.berkeley.edu/%7Estevedh>
> Hi Nithin,
>
> I'm having the same problem in these weeks.
> Also with the increased timeout I still receive duplicated packets. Did
> you
> solve the problem?
> What if you use different platforms instead of iris?
>
> 2010/12/20 Nithin K N <nit...@ece.iisc.ernet.in>
>
>> Hello all,
>> in iris motes
>> 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 <mmar...@math.u-szeged.hu>
>> 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 <nithin6low...@gmail.com>
>> 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 <nithin6low...@gmail.com>
>> > Date: Thu, Oct 7, 2010 at 6:47 PM
>> > Subject: Fwd: [Tinyos-help] Fwd: UDPEcho in iris
>> > To: Miklos Maroti <mmar...@gmail.com>
>> >
>> >
>> > the pinging to iris stops every 165 (on an average) . what may be
>> the reason
>> > ?
>> >
>> > ---------- Forwarded message ----------
>> > From: Miklos Maroti <mmar...@math.u-szeged.hu>
>> > Date: 2010/9/21
>> > Subject: Re: [Tinyos-help] Fwd: UDPEcho in iris
>> > To: Zsolt Szabó <szabomeis...@gmail.com>
>> > Cc: Stephen Dawson-Haggerty <stev...@eecs.berkeley.edu>, nithin k n
>> > <nithin6low...@gmail.com>, tinyos-help@millennium.berkeley.edu,
>> Veress
>> > Krisztián <veresskriszt...@gmail.com>, Bíró András <
>> bband...@gmail.com>
>> >
>> >
>> > 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
>> >>>> > 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
>> >>>> >
>> >>>
>> >>>
>> >>
>> >
>> >
>> >
>>
>>
>>
>> Nithin
>>
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>> _______________________________________________
>> Tinyos-help mailing list
>> Tinyos-help@millennium.berkeley.edu
>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
