Date: Wed, 20 Sep 2017 06:45:45 -0400 From: Chris Gordon <chris@theory14.net> To: Russell Haley <russ.haley@gmail.com> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Unexpected Results from nuttcp testing wifi on arm Message-ID: <7BCF4E27-E82F-4192-9660-E9F822C6E5A7@theory14.net> In-Reply-To: <CABx9NuT_6JEWEhwjpvmPsEoQLeA7QHaeQ_Tt5seKFrDMJdN53w@mail.gmail.com> References: <CABx9NuRjxrauDTpM=yam=Bpw-Wx6CHP8DVcpxV9WwE0tfutN6g@mail.gmail.com> <CABx9NuT_6JEWEhwjpvmPsEoQLeA7QHaeQ_Tt5seKFrDMJdN53w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Not that it=E2=80=99s a good control experiment, but I found a CLI = version of the internet speed tests = (https://github.com/sivel/speedtest-cli)*. It generated similar results = as to using nuttcp against a desktop (wired) on my network indicating = that the BBB was the limiting device. Chris * Requires python and a couple of other packages to build/install. > On Sep 20, 2017, at 2:07 AM, Russell Haley <russ.haley@gmail.com> = wrote: >=20 > Hi, >=20 > 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. :-/ >=20 > Russ >=20 > On Sat, Sep 16, 2017 at 11:18 PM, Russell Haley <russ.haley@gmail.com> = wrote: >> Hi, >>=20 >> 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. >>=20 >> When testing wifi on my imx6 (hummingboard) I get drastically >> different results depending on which side is the client or the = server. >>=20 >> Host =3D amd64 TrueOS wired 100Mbps >> Target =3D imx6 FBSD 12 wifi (MAC/BBP RT3572 ) >>=20 >>=20 >> 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 >>=20 >> ----------------------------------------------------------- >>=20 >> imx6 client -> amd64 (wired) Server >> root@imx6:~ # nuttcp -i 1 -v -n 1000 prescott > /tmp/out.txt >>=20 >> http://termbin.com/8vvh >> #Summary: >> nuttcp-t: 9.0000 MB in 108.96 real seconds =3D 84.58 KB/sec =3D = 0.6929 Mbps >>=20 >> Is this abnormal? (Please say yes!) >>=20 >> Russ (more setup details below) >>=20 >>=20 >> IMX6 test setup: >>=20 >> 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/a= rm.armv6/usr/home/russellh/FreeBSD/rh-armv6/src/sys/IMX6 >> arm >>=20 >> 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 >>=20 >> #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> >>=20 >>=20 >> #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 >>=20 >> 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_MAGI= C,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 >>=20 >>=20 >> ---------- 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> >>=20 >>=20 >> On Tue, Sep 12, 2017 at 7:00 PM, Chris Gordon <freebsd@theory14.net> = wrote: >>>=20 >>>> On Sep 6, 2017, at 8:13 PM, Russell Haley <russ.haley@gmail.com> = wrote: >>>>=20 >>>> 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. >>>>=20 >>>> Have fun! (sob, sob, sob). ;) >>>=20 >>> Sorry you missed it. I agree that timing wasn=E2=80=99t great with = a holiday weekend (for the US at least) on one side and EuroBSDcon very = soon afterward, but constraints on the availability of the hotel drove = the exact date. Maybe we can see you in 2019 (we do the conference = every other year, opposite MeetBSD). >>>=20 >>>>>> I used nuttcp for testing the wired connection, so I would plan = to use that for the Wifi. >>>>=20 >>>> nuttcp. Got it, I'll start playing with it. >>>=20 >>> For the testing described in my original email and the data below, I = used the most basic options from = https://fasterdata.es.net/performance-testing/network-troubleshooting-tool= s/nuttcp/. Specifically: >>>=20 >>> Server: >>> nuttcp -S >>>=20 >>> Client: >>> nuttcp -i1 server_hostname >>> and >>> nuttcp -i1 -r server_hostname >>>=20 >> nuttcp client only runs for a maybe 10 requests (it varies) and then = stops? >>=20 >> 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 >>=20 >> 9.6159 MB / 10.19 sec =3D 7.9151 Mbps 0 %TX 2 %RX 0 = host-retrans >> 2.19 msRTT >>=20 >> 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. >>=20 >> I also can't connect to wpa_cli? Error: >>=20 >> % wpa_cli >> wpa_cli v2.5 >> Copyright (c) 2004-2015, Jouni Malinen <j@w1.fi> and contributors >>=20 >> This software may be distributed under the terms of the BSD >> license. >> See README for more details. >>=20 >>=20 >>=20 >> Interactive mode >>=20 >> Could not connect to wpa_supplicant: (nil) - re-trying >> ^c >>=20 >> The interweb says on Linux I need to adjust my wpa_supplicant.conf so >> I will try that. >>=20 >> 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. >>=20 >> Night, >>=20 >> Russ >>=20 >>=20 >>>>>> - 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. >>>>>=20 >>>>> Yes, that should be easy to do, but will be next week before I = have a chance. >>>=20 >>> 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 various 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 (again, it=E2=80=99s an old access point, circa 2008, so I don=E2=80= =99t expect 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 more than 10 Mbps to the internet through the same = access point that the BBB is using. >>>=20 >>> I=E2=80=99ll follow up with what I see in the morning. My theories = at this time (neither very good) are: >>>=20 >>> - There is a lot of wifi congestion around me and when others are = heavily using their wifi, I suffer. This is exacerbated by something = about the usb wifi NIC I have in the BBB. This doesn=E2=80=99t impact = the iPad or other devices due to differences in antennae or some other = aspect of their devices. 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. >>>=20 >>> Thanks, >>> Chris >>>=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7BCF4E27-E82F-4192-9660-E9F822C6E5A7>