[Nfd-dev] Extremely high RTT on raspberry pi with the clean version

[Anthony Dowling]

That makes sense. I did some research on txpower, and found that 31 is the
maximum, so I used 14, since it is about in the middle, and network manager
sets it around that by default.

Thanks,
Anthony

On Tue, Jan 2, 2018 at 2:36 PM, Ashlesh Gawande (agawande) <
agawande at memphis.edu> wrote:

> In our lab we saw that with poor power supply the RPi would hang if we try
> to use the WiFi. With power management it was somewhat better (and also the
> ssh did not get dropped randomly). I have no idea about txpower - why do
> you set it to 14?
>
> Ashlesh
> On Jan 2, 2018 1:25 PM, Anthony Dowling <dowlinah at clarkson.edu> wrote:
>
> The power supply I am using is an anker power core 20100 (
> https://www.anker.com/products/variant/PowerCore-20100mAh/A1271012 ) it
> is rated to 2.4A per output, and it has worked properly previously for
> using NFD. Forgive my ignorance, but what does power management do? Does
> that have to do with txpower? I am using a script to set the txpower, and
> it was set to 14.
>
> Thanks,
> Anthony
>
> On Tue, Jan 2, 2018 at 2:17 PM, Ashlesh Gawande (agawande) <
> agawande at memphis.edu> wrote:
>
> Is power management off on the wireless interface? What is the rating of
> the power supply (Ideal is 5V, 2.5A)?
>
>
> Ashlesh
> ------------------------------
> *From:* Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu> on behalf of Anthony
> Dowling <dowlinah at clarkson.edu>
> *Sent:* Tuesday, January 2, 2018 1:09:55 PM
> *To:* Davide Pesavento; <nfd-dev at lists.cs.ucla.edu>
> *Subject:* Re: [Nfd-dev] Extremely high RTT on raspberry pi with the
> clean version
>
> Davide,
>
> I apologize, the clocks aren't synchronized. However, I don't think its
> due to interference or distance, as they were less than 2 feet apart, and
> the radio interference was minimal, as I was 2 miles away from an
> electrical pole with very few other electrical items in operation around me
> that could have caused interference, and no other wi-fi networks anywhere
> near me. However, I will use what you have told me to see if I can find the
> issue. Thanks for the help.
>
> Anthony
>
> On Tue, Jan 2, 2018 at 2:02 PM, Davide Pesavento <davide.pesavento at lip6.fr
> > wrote:
>
> On Tue, Jan 2, 2018 at 1:22 PM, Anthony Dowling <dowlinah at clarkson.edu>
> wrote:
> > Hello all,
> >
> > I am working with NFD on the raspberry pi 3 model B system. Lately,
> however,
> > I have had a very strange issue. While using ndnping over 1 hop in an
> adhoc
> > environment over ethernet multicast faces, the round trip time can be
> > upwards of 10 minutes. I was working with a modified version when I
> > encountered this issue, however, after reinstalling the clean version
> from
> > github, the problem persisted. So, I used the trace level logging to see
> > what could be going on, but I am unable to find the issue. Does anyone
> have
> > an idea what could be causing this issue?
> >
> > Below is the trace from each side, organized into the order that I
> believe
> > the events took place, however, I am unsure if this is actually the
> case, as
> > there is a chance that the producer responded to the interest after the
> > timeout took place on the consumer.
> >
>
> Hi Anthony,
>
> You're showing logs from two different hosts, are the clocks synchronized?
>
> Maybe it's just a case of high packet loss on the wireless medium, due
> to interference, distance, or other factors. Can you check if/when the
> packets are actually received on the physical interface using e.g.
> tcpdump?
>
> Another thing you could try is: build NFD in debug mode (./waf
> configure --debug) and look for the log line that says "Detected <X>
> dropped frame(s)".
>
> Best regards,
> Davide
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20180102/24679a44/attachment.html>