Date: Tue, 19 Sep 2017 23:07:01 -0700 From: Russell Haley <russ.haley@gmail.com> To: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Unexpected Results from nuttcp testing wifi on arm Message-ID: <CABx9NuT_6JEWEhwjpvmPsEoQLeA7QHaeQ_Tt5seKFrDMJdN53w@mail.gmail.com> In-Reply-To: <CABx9NuRjxrauDTpM=yam=Bpw-Wx6CHP8DVcpxV9WwE0tfutN6g@mail.gmail.com> References: <CABx9NuRjxrauDTpM=yam=Bpw-Wx6CHP8DVcpxV9WwE0tfutN6g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, So I am consistently getting very low throughput when testing with nuttcp if I use my arm board as the client. If the desktop is the client, I am averaging ~8 Mbps. When my arm board is the client, I get an average of just over 1 Mbps. This doesn't seem right to me. Any input or confirmation that this is incorrect would be grand. My assumption is I have done something wrong. :-/ Russ On Sat, Sep 16, 2017 at 11:18 PM, Russell Haley <russ.haley@gmail.com> wrot= e: > Hi, > > Well I WAS going to bed and then I looked at the results of my testing > for the BBB/wifi stuff. This is NOT on a BBB and I have a different > wifi adapter so I started a new post. > > When testing wifi on my imx6 (hummingboard) I get drastically > different results depending on which side is the client or the server. > > Host =3D amd64 TrueOS wired 100Mbps > Target =3D imx6 FBSD 12 wifi (MAC/BBP RT3572 ) > > > amd64 (wired) client -> imx6 Server > russellh@prescott:~% nuttcp -n 1000 -v -i1 192.168.2.62 > /tmp/prescott1.= out > http://termbin.com/7o1w > #Summary: > nuttcp-t: 62.5000 MB in 60.77 real seconds =3D 1053.13 KB/sec =3D 8.6273 = Mbps > > ----------------------------------------------------------- > > imx6 client -> amd64 (wired) Server > root@imx6:~ # nuttcp -i 1 -v -n 1000 prescott > /tmp/out.txt > > http://termbin.com/8vvh > #Summary: > nuttcp-t: 9.0000 MB in 108.96 real seconds =3D 84.58 KB/sec =3D 0.6929 Mb= ps > > Is this abnormal? (Please say yes!) > > Russ (more setup details below) > > > IMX6 test setup: > > root@imx6:~ # uname -a > FreeBSD imx6 12.0-CURRENT FreeBSD 12.0-CURRENT #13 r321601M: Thu Sep > 14 20:43:21 PDT 2017 > russellh@prescott.highfell.local:/usr/home/russellh/FreeBSD/rh-armv6/obj/= arm.armv6/usr/home/russellh/FreeBSD/rh-armv6/src/sys/IMX6 > arm > > root@imx6:~ # dmesg | grep run0 > run0 on uhub2 > run0: <1.0> on usbus1 > run0: MAC/BBP RT3572 (rev 0x0223), RF RT3052 (MIMO 2T2R), address > 60:a4:4c:ec:c9:a5 > run0: firmware RT3071 ver. 0.33 loaded > > #root@imx6:~ # ifconfig wlan0 > wlan0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu = 1500 > ether 60:a4:4c:ec:c9:a5 > hwaddr 60:a4:4c:ec:c9:a5 > inet 192.168.2.62 netmask 0xffffff00 broadcast 192.168.2.255 > groups: wlan > ssid Haleys_DownStairs channel 8 (2447 MHz 11g) bssid ac:9e:17:67= :85:90 > regdomain FCC country US authmode WPA2/802.11i privacy ON > deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 7 scanvalid 60 > protmode CTS wme roaming MANUAL > media: IEEE 802.11 Wireless Ethernet DS/1Mbps mode 11g > status: associated > nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> > > > #amd64 test setup: > russellh@prescott:~% uname -a > FreeBSD prescott.highfell.local 12.0-CURRENT FreeBSD 12.0-CURRENT #66 > ac2f0aa3b(trueos-stable)-dirty: Wed Jun 21 01:09:23 UTC 2017 > root@gauntlet:/usr/obj/usr/src/sys/GENERIC amd64 > > russellh@prescott:~% ifconfig re0 > re0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu > 1500 > options=3D8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM= ,WOL_MAGIC,LINKSTATE> > ether 0c:54:a5:18:c1:5b > hwaddr 0c:54:a5:18:c1:5b > inet6 fe80::e54:a5ff:fe18:c15b%re0 prefixlen 64 scopeid 0x1 > inet 192.168.2.47 netmask 0xffffff00 broadcast 192.168.2.255 > nd6 options=3D23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL> > media: Ethernet autoselect (100baseTX <full-duplex>) > status: active > > > ---------- Forwarded message ---------- > From: Russell Haley <russ.haley@gmail.com> > Date: Sat, Sep 16, 2017 at 10:43 PM > Subject: Re: Beaglebone Black + FreeBSD + USB WiFi =3D WAP? > To: Chris Gordon <freebsd@theory14.net> > > > On Tue, Sep 12, 2017 at 7:00 PM, Chris Gordon <freebsd@theory14.net> wrot= e: >> >>> On Sep 6, 2017, at 8:13 PM, Russell Haley <russ.haley@gmail.com> wrote: >>> >>> Argh! I was just in Maryland and we flew home from Dulles!!! I made >>> the client push the date forward to last week so I could be home for >>> Labour Day. >>> >>> Have fun! (sob, sob, sob). ;) >> >> Sorry you missed it. I agree that timing wasn=E2=80=99t great with a ho= liday weekend (for the US at least) on one side and EuroBSDcon very soon af= terward, but constraints on the availability of the hotel drove the exact d= ate. Maybe we can see you in 2019 (we do the conference every other year, = opposite MeetBSD). >> >>>>> I used nuttcp for testing the wired connection, so I would plan to us= e that for the Wifi. >>> >>> nuttcp. Got it, I'll start playing with it. >> >> For the testing described in my original email and the data below, I use= d the most basic options from https://fasterdata.es.net/performance-testing= /network-troubleshooting-tools/nuttcp/. Specifically: >> >> Server: >> nuttcp -S >> >> Client: >> nuttcp -i1 server_hostname >> and >> nuttcp -i1 -r server_hostname >> > nuttcp client only runs for a maybe 10 requests (it varies) and then stop= s? > > root@imx6:~ # nuttcp -i1 -r prescott > 0.9375 MB / 1.01 sec =3D 7.8054 Mbps > 1.0000 MB / 0.99 sec =3D 8.4466 Mbps > 0.9375 MB / 1.00 sec =3D 7.8644 Mbps > 0.9375 MB / 1.00 sec =3D 7.8643 Mbps > 0.9375 MB / 1.05 sec =3D 7.4824 Mbps > 0.9375 MB / 0.95 sec =3D 8.2873 Mbps > 0.9375 MB / 1.00 sec =3D 7.8643 Mbps > 1.0625 MB / 1.00 sec =3D 8.9129 Mbps > 0.9375 MB / 1.00 sec =3D 7.8640 Mbps > 0.8750 MB / 1.00 sec =3D 7.3403 Mbps > > 9.6159 MB / 10.19 sec =3D 7.9151 Mbps 0 %TX 2 %RX 0 host-retrans > 2.19 msRTT > > This is true with both my host (amd64 TrueOS/FBSD 12-Current) and my > humingboard (imx6 12-current). I tried to force it with -n 1000 and > got maybe 20 requests. Verbose didn't tell me anything about why it > stopped. > > I also can't connect to wpa_cli? Error: > > % wpa_cli > wpa_cli v2.5 > Copyright (c) 2004-2015, Jouni Malinen <j@w1.fi> and contributors > > This software may be distributed under the terms of the BSD > license. > See README for more details. > > > > Interactive mode > > Could not connect to wpa_supplicant: (nil) - re-trying > ^c > > The interweb says on Linux I need to adjust my wpa_supplicant.conf so > I will try that. > > I'm having trouble sifting all the emails so I apologise if you've > already answered this. Have you done a tcpdump capture of the system > and checked if there is anything telling in the transmissions? If I > remember correctly you can roll the file output to make it digestible. > I've used sshfs once on Linux to transfer to a host computer that had > more storage (perhaps over serial would reduce test-effect on the > unit?), but sd cards are nice and big now. > > Night, > > Russ > > >>>>> - Can you run the bbb as a standard device (not an access point) and >>>>> test the performance of the wlan0 interface using the method of >>>>> measurement pointed above? I will do the same at some point with my >>>>> wi-fi dongle. >>>> >>>> Yes, that should be easy to do, but will be next week before I have a = chance. >> >> I did the above -- setup the BBB as a simple WiFi client to my existing = (ancient) access point. I ran nuttcp between the BBB and my desktop (wired= network, access point connected to same wired network). Both the BBBB and= desktop were run as server and client for nuttcp. Many runs of the variou= s combinations were run. I saw the following: >> - In general between 10 and 20 Mbps, typically on the lower side. This = is consistent for what I see for other devices going to my access point (ag= ain, it=E2=80=99s an old access point, circa 2008, so I don=E2=80=99t expec= t too much from it) >> - I did have one period of slow traffic, 1 Mbps and lower. After a few= runs of this, I did a =E2=80=9Cservice netif restart=E2=80=9D, dealt with = pets for a couple of minutes and when I returned performance was back. >> - I just hit another period of slow traffic, but this is around 2.5 Mbps= instead of the really bad < 1 Mbps. Instead of resetting the network, I= =E2=80=99m going to let the BBB sit until morning and test again then. I = did test my iPad with a speed test app and it=E2=80=99s getting a little mo= re than 10 Mbps to the internet through the same access point that the BBB = is using. >> >> I=E2=80=99ll follow up with what I see in the morning. My theories at = this time (neither very good) are: >> >> - There is a lot of wifi congestion around me and when others are heavil= y using their wifi, I suffer. This is exacerbated by something about the u= sb wifi NIC I have in the BBB. This doesn=E2=80=99t impact the iPad or oth= er devices due to differences in antennae or some other aspect of their dev= ices. This idea doesn=E2=80=99t quite fit with everything, but a guess. >> - There is something in kernel or wireless stack that degrades over time= /amount of traffic passed that ends up limiting performance. >> >> Thanks, >> Chris >>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABx9NuT_6JEWEhwjpvmPsEoQLeA7QHaeQ_Tt5seKFrDMJdN53w>