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>