Date: Sat, 23 Sep 2017 22:10:17 -0700 From: Russell Haley <russ.haley@gmail.com> To: Chris Gordon <freebsd@theory14.net> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Beaglebone Black + FreeBSD + USB WiFi = WAP? Message-ID: <CABx9NuRJz7yp8MV=zT1iUe2nr8MB92XUG3MNuwBsmn32u-Ewhg@mail.gmail.com> In-Reply-To: <CABx9NuTt2Y0VQ4QUtgoXOuj3VjCGfu9Y8krp4KyuRUG4WX89Ww@mail.gmail.com> References: <40EA308E-489D-4A0B-B75A-2CA5A4EC474E@theory14.net> <685d0eed3532a34f239e7ff893f817db@bakulin.de> <EB1907C8-7A0A-4D45-AD21-B449DC4C0D7D@theory14.net> <CABx9NuQCrspSzcdXh0_cbO1QmexwQbrk1djaGyvKTp370AtxYA@mail.gmail.com> <CABx9NuQJWot9xgs1QtzJ87NfgZM=FPhZ%2B2a-RewDonvGG5LLKg@mail.gmail.com> <CABx9NuT1n8ZYPrZTB8vT2sBmT3U75E4UFgAGA3ZOPTotpsUWeg@mail.gmail.com> <CABx9NuQB=xBNt6%2BX=YKw4XVW5u1XysW%2Bo7pqO_9D2RC%2BF6bKug@mail.gmail.com> <20170905141711.6545490.14963.31294@gmail.com> <656A5193-7389-476C-AF58-EB013E9155F3@theory14.net> <CABx9NuQtXRbN6YPihotuLSnE5cFG-xvRRNYyFSLGxZNPBnKTKQ@mail.gmail.com> <E1992F2B-236D-467C-AAEE-B81A59EB1138@theory14.net> <CABx9NuTTewBiuesSxWsWsJg2HeRZFPeNU1WSRpqxEALxSUEhkw@mail.gmail.com> <CABx9NuTxS_Pc_tko3HZyCFhMLvQa8bVDGx308aLJaG_8JHhu-Q@mail.gmail.com> <CABx9NuTt2Y0VQ4QUtgoXOuj3VjCGfu9Y8krp4KyuRUG4WX89Ww@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@prescott:~% nuttcp -i 1 192.168.2.62
2.1250 MB / 1.00 sec =3D 17.7976 Mbps
3.8750 MB / 1.00 sec =3D 32.4830 Mbps
3.5000 MB / 1.00 sec =3D 29.4280 Mbps
3.0000 MB / 1.00 sec =3D 25.1649 Mbps
3.0000 MB / 1.00 sec =3D 25.1623 Mbps
2.9375 MB / 1.00 sec =3D 24.6420 Mbps
2.9375 MB / 1.00 sec =3D 24.6355 Mbps
3.3125 MB / 1.00 sec =3D 27.7635 Mbps
3.1875 MB / 1.00 sec =3D 26.7693 Mbps
1.3125 MB / 1.00 sec =3D 11.0108 Mbps
29.8267 MB / 10.39 sec =3D 24.0905 Mbps 0 %TX 18 %RX 176
host-retrans 2.04 msRTT
#Debian client (BBB, Wifi) -> FreeBSD server (wired, 100 Mbps)
debian@beaglebone:~$ nuttcp -i 1 -r 192.168.2.47
2.9375 MB / 1.00 sec =3D 24.6398 Mbps
3.5000 MB / 1.00 sec =3D 29.3551 Mbps
3.5000 MB / 1.00 sec =3D 29.3135 Mbps
3.7500 MB / 1.00 sec =3D 31.4984 Mbps
4.0000 MB / 1.00 sec =3D 33.5589 Mbps
3.9375 MB / 1.00 sec =3D 33.0372 Mbps
3.6875 MB / 1.00 sec =3D 30.9209 Mbps
3.6875 MB / 1.00 sec =3D 30.9398 Mbps
3.4375 MB / 1.00 sec =3D 28.8192 Mbps
3.4375 MB / 1.00 sec =3D 28.7767 Mbps
36.5883 MB / 10.15 sec =3D 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@gmail.com> wrote=
:
> On Thu, Sep 7, 2017 at 12:03 AM, Russell Haley <russ.haley@gmail.com> wro=
te:
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221845#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 con=
sole
>
> Russ
>
>>
>> zzz,
>> Russ
>>
>> On Wed, Sep 6, 2017 at 5:13 PM, Russell Haley <russ.haley@gmail.com> wro=
te:
>>> On Wed, Sep 6, 2017 at 3:30 PM, Chris Gordon <freebsd@theory14.net> wro=
te:
>>>> 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 sessi=
ons (via wired NIC) into the BBB. There is no panic other other messages o=
n the console. The devices remains responsive to user input/actions via ss=
h. In a previous reply to my initial inquiry, Ilya Bakulin asked about outp=
ut from "top -Sa=E2=80=9D thinking the CPU was overwhelmed. The system sta=
ys 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=E2=80=99t be until next week when I can look at any of these. =
I=E2=80=99m one of the organizers at vBSDcon and will be at the Dev Summit =
and conference through the weekend. If anyone is interested, I=E2=80=99m h=
appy 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 oth=
er than i-devices. I used nuttcp for testing the wired connection, so I wo=
uld 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 t=
o
>>>>> be difficult though as pausing the kernel in the middle of TCP traffi=
c
>>>>> 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=E2=80=99ll get some info as soon as I can. A=
nything important I=E2=80=99ll 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABx9NuRJz7yp8MV=zT1iUe2nr8MB92XUG3MNuwBsmn32u-Ewhg>