Unexpected Results from nuttcp testing wifi on arm

Russell Haley russ.haley at gmail.com
Sun Sep 17 06:18:10 UTC 2017


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 = amd64 TrueOS wired 100Mbps
Target = imx6  FBSD 12 wifi  (MAC/BBP RT3572 )


amd64 (wired) client -> imx6 Server
russellh at 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 = 1053.13 KB/sec = 8.6273 Mbps

-----------------------------------------------------------

imx6 client -> amd64 (wired) Server
root at 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 = 84.58 KB/sec = 0.6929 Mbps

Is this abnormal? (Please say yes!)

Russ (more setup details below)


IMX6 test setup:

root at imx6:~ # uname -a
FreeBSD imx6 12.0-CURRENT FreeBSD 12.0-CURRENT #13 r321601M: Thu Sep
14 20:43:21 PDT 2017
russellh at prescott.highfell.local:/usr/home/russellh/FreeBSD/rh-armv6/obj/arm.armv6/usr/home/russellh/FreeBSD/rh-armv6/src/sys/IMX6
 arm

root at 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 at imx6:~ # ifconfig wlan0
wlan0: flags=8843<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=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>


#amd64 test setup:
russellh at 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 at gauntlet:/usr/obj/usr/src/sys/GENERIC  amd64

russellh at prescott:~% ifconfig re0
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
1500
        options=8209b<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=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active


---------- Forwarded message ----------
From: Russell Haley <russ.haley at gmail.com>
Date: Sat, Sep 16, 2017 at 10:43 PM
Subject: Re: Beaglebone Black + FreeBSD + USB WiFi = WAP?
To: Chris Gordon <freebsd at theory14.net>


On Tue, Sep 12, 2017 at 7:00 PM, Chris Gordon <freebsd at theory14.net> wrote:
>
>> On Sep 6, 2017, at 8:13 PM, Russell Haley <russ.haley at 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’t 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).
>
>>>> I used nuttcp for testing the wired connection, so I would plan to use 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 used 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 stops?

root at imx6:~ # nuttcp -i1 -r prescott
    0.9375 MB /   1.01 sec =    7.8054 Mbps
    1.0000 MB /   0.99 sec =    8.4466 Mbps
    0.9375 MB /   1.00 sec =    7.8644 Mbps
    0.9375 MB /   1.00 sec =    7.8643 Mbps
    0.9375 MB /   1.05 sec =    7.4824 Mbps
    0.9375 MB /   0.95 sec =    8.2873 Mbps
    0.9375 MB /   1.00 sec =    7.8643 Mbps
    1.0625 MB /   1.00 sec =    8.9129 Mbps
    0.9375 MB /   1.00 sec =    7.8640 Mbps
    0.8750 MB /   1.00 sec =    7.3403 Mbps

    9.6159 MB /  10.19 sec =    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 at 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 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’s an old access point, circa 2008, so I don’t 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 “service netif restart”, 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’m going to let the BBB sit until morning and test again then.   I did test my iPad with a speed test app and it’s getting a little more than 10 Mbps to the internet through the same access point that the BBB is using.
>
> I’ll 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 heavily using their wifi, I suffer.  This is exacerbated by something about the usb wifi NIC I have in the BBB.  This doesn’t impact the iPad or other devices due to differences in antennae or some other aspect of their devices.  This idea doesn’t 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
>


More information about the freebsd-arm mailing list