From owner-freebsd-arm@freebsd.org Sun Sep 24 05:10:21 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 841FDE1F40F for ; Sun, 24 Sep 2017 05:10:21 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E28B96A1C9 for ; Sun, 24 Sep 2017 05:10:20 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x22d.google.com with SMTP id m199so4087149lfe.3 for ; Sat, 23 Sep 2017 22:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=w9cYJBgG94x2+43Zt2VmKdzklhhp88i7P2fhUIVafbI=; b=t03eeQnpPpgJeY73fXUyijC4UEm3OGHnT7CywYaL0WUE4mwCEtMs/0167D1Jza4PqW f/T5Gm2BDMsHwU3LjntPwBwSUxWJDULUKmbKwRcRtB+zqm07+rIsGxY92IDLczmq5ES0 pY7cc80JU6GSjjRs2dMv1K1sOheUzstT8yt2iYNhoNaaQvRQZfQXnXa/7MYxSZMkdFQn DwuOZe75cWnTevfRkFASuBDF0Yt6OxR6ldtfkuKUx/TorCGFUTPspoyQkCK5YD9Kwf0r v46QAS4CSDMyaV9eMJSMwNAuaqBxdHBGEbpp6X9FDkB7b/DUsZiTU5g36mNrIAtt3J2x Yi4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=w9cYJBgG94x2+43Zt2VmKdzklhhp88i7P2fhUIVafbI=; b=Nfia2Z6JBjvYBhHFGZjrwUrF1S0FzCgA3JFbMDNyQWxzcr721VxZBOqqEvD0vDXvEq 9LhqwMjkS1AU8cPGuCU1Lv4PtcClmLPQ0PLuuGyHdx5mWMyZNsMZYi8uU/1OkvOcbElB W+7jqk07wri6gkRhHtagrZX8BaIZ6Tf/ihpi49X/EEJZlO5q7LzFBVqoBdK5w4kuGH6l d1F9ibaPux6fD9BWTK89U0DCsMf7EqIcaTh/X7ASOtDw32zKhg6s3OVyu5D+EATzoYw0 GAR3mM3aOblMaYQ7Witg2ieQGzvXdO7WMOrwwFXVJCUQ+PscePUcef2qgNBkFGX0Xs/g udAQ== X-Gm-Message-State: AHPjjUhgjlb3mgpg2+6ded0DmYpGsB/No5douMD3WUFb2jxO7K8paUke yiE70mHBePMBtEjnvh2TsLxvkOxodplgxKcjYOWJtw== X-Google-Smtp-Source: AOwi7QCbVlb4s5wu8ZmMG0//JFpYTammUN7I/73+YFs32cAnUzaTa1aNr9ShnC76johhc2KxH7JilcdPnW5DDpaoYnk= X-Received: by 10.25.81.85 with SMTP id f82mr1114778lfb.70.1506229818801; Sat, 23 Sep 2017 22:10:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.65 with HTTP; Sat, 23 Sep 2017 22:10:17 -0700 (PDT) In-Reply-To: References: <40EA308E-489D-4A0B-B75A-2CA5A4EC474E@theory14.net> <685d0eed3532a34f239e7ff893f817db@bakulin.de> <20170905141711.6545490.14963.31294@gmail.com> <656A5193-7389-476C-AF58-EB013E9155F3@theory14.net> From: Russell Haley Date: Sat, 23 Sep 2017 22:10:17 -0700 Message-ID: Subject: Re: Beaglebone Black + FreeBSD + USB WiFi = WAP? To: Chris Gordon Cc: freebsd-arm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Sep 2017 05:10:21 -0000 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 wrote= : > On Thu, Sep 7, 2017 at 12:03 AM, Russell Haley 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] [] (unwind_backtrace+0x1/0x9c) from > [] (panic+0x59/0x15c) > [ 480.562746] [] (panic+0x59/0x15c) from [] > (watchdog+0x19d/0x1c0) > [ 480.570972] [] (watchdog+0x19d/0x1c0) from [] > (kthread+0x6b/0x78) > [ 480.579294] [] (kthread+0x6b/0x78) from [] > (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 wro= te: >>> On Wed, Sep 6, 2017 at 3:30 PM, Chris Gordon 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