Beaglebone Black + FreeBSD + USB WiFi = WAP?

[Russell Haley]

Hi,

First off, I understand my RT3052 may not be considered a well
supported chipset. However, I thought I'd run a comparison on the BBB
using GNU/Linux. Once I got the adapter working (RT3052) under Debian
Jessie I started doing the same tests against my TrueOS amd64 machine:

#FreeBSD client (wired, 100 Mbps) -> Debian server (BBB, Wifi)

russellh at prescott:~% nuttcp -i 1 192.168.2.62
    2.1250 MB /   1.00 sec =   17.7976 Mbps
    3.8750 MB /   1.00 sec =   32.4830 Mbps
    3.5000 MB /   1.00 sec =   29.4280 Mbps
    3.0000 MB /   1.00 sec =   25.1649 Mbps
    3.0000 MB /   1.00 sec =   25.1623 Mbps
    2.9375 MB /   1.00 sec =   24.6420 Mbps
    2.9375 MB /   1.00 sec =   24.6355 Mbps
    3.3125 MB /   1.00 sec =   27.7635 Mbps
    3.1875 MB /   1.00 sec =   26.7693 Mbps
    1.3125 MB /   1.00 sec =   11.0108 Mbps

   29.8267 MB /  10.39 sec =   24.0905 Mbps 0 %TX 18 %RX 176
host-retrans 2.04 msRTT

#Debian client (BBB, Wifi) -> FreeBSD server (wired, 100 Mbps)

debian at beaglebone:~$ nuttcp -i 1 -r 192.168.2.47
    2.9375 MB /   1.00 sec =   24.6398 Mbps
    3.5000 MB /   1.00 sec =   29.3551 Mbps
    3.5000 MB /   1.00 sec =   29.3135 Mbps
    3.7500 MB /   1.00 sec =   31.4984 Mbps
    4.0000 MB /   1.00 sec =   33.5589 Mbps
    3.9375 MB /   1.00 sec =   33.0372 Mbps
    3.6875 MB /   1.00 sec =   30.9209 Mbps
    3.6875 MB /   1.00 sec =   30.9398 Mbps
    3.4375 MB /   1.00 sec =   28.8192 Mbps
    3.4375 MB /   1.00 sec =   28.7767 Mbps

   36.5883 MB /  10.15 sec =   30.2344 Mbps 0 %TX 20 %RX 0
host-retrans 1.31 msRTT


For what it's worth,

Russ


On Sat, Sep 23, 2017 at 9:32 PM, Russell Haley <russ.haley at gmail.com> wrote:
> On Thu, Sep 7, 2017 at 12:03 AM, Russell Haley <russ.haley at gmail.com> wrote:
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221845#c3
>>
>> I've been following the code through and wound up at
>> sys/arm/ti/cpsw/if_cpsw.c. cpsw_intr_rx [which] is defined on line
>> 1554. The function uses a macro called CPSW_RX_LOCK which is defined
>> on line 349. The macro contains an assert on a transmit lock
>> (tx.lock). I theorise the statement on line 350 is causing my
>> exception? I also wonder if the lock being held between lines 1561 and
>> 1570 is causing the delay in the bridge interface that is causing the
>> original posters' slow throughput. Is it necessary to hold the lock
>> until after the cpsw_write_4 on line 1569 or could it be performed
>> outside the lock?
>
> Well, for what it's worth, Debian on my BBB doesn't think much of my
> wifi adapter much either:
>
> [  480.532193] INFO: task ifconfig:1369 blocked for more than 60 seconds.
> [  480.539231] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> disables this message.
> [  480.547647] Kernel panic - not syncing: hung_task: blocked tasks
> [  480.554065] [<c00114f1>] (unwind_backtrace+0x1/0x9c) from
> [<c04d0abd>] (panic+0x59/0x15c)
> [  480.562746] [<c04d0abd>] (panic+0x59/0x15c) from [<c0073915>]
> (watchdog+0x19d/0x1c0)
> [  480.570972] [<c0073915>] (watchdog+0x19d/0x1c0) from [<c00454ab>]
> (kthread+0x6b/0x78)
> [  480.579294] [<c00454ab>] (kthread+0x6b/0x78) from [<c000c8fd>]
> (ret_from_fork+0x11/0x34)
> [  480.587874] drm_kms_helper: panic occurred, switching back to text console
>
> Russ
>
>>
>> zzz,
>> Russ
>>
>> On Wed, Sep 6, 2017 at 5:13 PM, Russell Haley <russ.haley at gmail.com> wrote:
>>> On Wed, Sep 6, 2017 at 3:30 PM, Chris Gordon <freebsd at theory14.net> wrote:
>>>> Russ,
>>>>
>>>>> Have you monitored your system on a serial console or direct console
>>>>> (i.e. via hdmi/keyboard)? Is the system still responding to other
>>>>> commands after you run the speed test? My thought is that the really
>>>>> really low bandwidth belies a kernel panic on the main terminal that
>>>>> you are not seeing.
>>>>
>>>> I have a serial console connected the entire time along with ssh sessions (via wired NIC) into the BBB.  There is no panic other other messages on the console.  The devices remains responsive to user input/actions via ssh. In a previous reply to my initial inquiry, Ilya Bakulin asked about output from "top -Sa” thinking the CPU was overwhelmed.  The system stays at >90% idle through the entire test (upload and download).  I see 2-4% WCPU for interrupts and 1-2% for USB.
>>>
>>> Good, thanks for clarifying.
>>>
>>>>> If you would like to do some further testing, you could perhaps help
>>>>> me answer these things:
>>>>
>>>> It won’t be until next week when I can look at any of these.  I’m one of the organizers at vBSDcon and will be at the Dev Summit and conference through the weekend.  If anyone is interested, I’m happy to bring my BBB there for debugging/testing on site.
>>>
>>> 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). ;)
>>>
>>>>> - Can you find a command line way of measuring throughput and latency
>>>>> separately that can be run on a host and on the bbb? I'm sure there
>>>>> are lots of ways to do so. I will leave it up to you to decide and
>>>>> will adopt the same tests so we can compare results.
>>>>
>>>> I just have to find another device -- I have everything wired here other than i-devices.  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.
>>>
>>>>> - 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.
>>>>
>>>>> Some tests I would like to do:
>>>>> - Get DTrace involved as a debugging tool. I have rudimentary DTrace
>>>>> skills but will need to consult my books on how to measure throughput
>>>>> and latency. There are some examples early in the DTrace book of
>>>>> logging system calls made by a process and I will review that again
>>>>> when time permits.
>>>>> - Run the system through the kernel debugger. I think this is going to
>>>>> be difficult though as pausing the kernel in the middle of TCP traffic
>>>>> might invalidate any results I get. I know how difficult it can be to
>>>>> debug threaded applications, I can't see a kernel being any easier. ;)
>>>>
>>>> I was thinking along the same lines and hampered only by lack of time and specific knowledge of what to start poking (of course, this is a great wqy to learn!).
>>>
>>> My random thought of the day is that the "down/receive" from eth0 to
>>> wlan0 is working somewhat correctly, but the "up/send" from wlan0 to
>>> eth0 is causing issues. This is coming from your throughput notes, and
>>> the fact I got a whole page downloaded, but received a panic when I
>>> was trying to request another page. My thought is to start looking at
>>> the send commands for wlan0 and USB.
>>>
>>>> Thanks for your help.  I’ll get some info as soon as I can.  Anything important I’ll add to the bug report.
>>>
>>> Thanks for having a fun problem to play with! Good luck with the
>>> conference and don't worry about time, I have 3 other things that I
>>> started this week alone. Anyone want to test a prototype Lua database?
>>> lolz.
>>>
>>> Russ