From owner-freebsd-arm@freebsd.org Thu Sep 7 07:03:55 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 9B148E0C437 for ; Thu, 7 Sep 2017 07:03:55 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 A56CF82109 for ; Thu, 7 Sep 2017 07:03:54 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x236.google.com with SMTP id 80so17608024lfy.4 for ; Thu, 07 Sep 2017 00:03:54 -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=Phg/5+vY3exfPzyp0+EAf9KfqnlvgyoCpV0wKEjvhW4=; b=rqUsQYAnH55yzs42kDyGncl70VRnJ8sX9/TVswOF4ZlYawAPa+IfHWM+oV1l2/zWZL ehnw3sY08s86rB4s8/ETke6V5ScXDkSCnFc6AC9I+YKyPNlgmFNYYwE8dtVcA3Nw8eEw DeaucBmtAJ6uI0qAI8Z/MXL9dzCnRZUT6e4SGK2oy0B35w+LAwO03vTxx9HLECqa+yvm vr1LnC/jQftVjrENrrNH7QXlljtJES3x0q9gUrqwWGOHdabQD7fsbwoMVj+vzN3FjCac DxN0KSicbzd0HNChzvkcDcpypK+gi/2cASRZedBUvm/2Pxk21GW4Gvm+odAs+DoUabfp Nbiw== 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=Phg/5+vY3exfPzyp0+EAf9KfqnlvgyoCpV0wKEjvhW4=; b=XNPoRFiboIUIzR1u3DanrZSBfX/NKe2/DeZTKCMSqDWhdsL29Ni6f0Y8IRJUVxwxi/ Ek66mlgCNBYJ+Q82D9PYIe2d4wPa1uh8hODNSEZ/w/Umccj7V5jvgKuXDnMIT85abbiu snMA3E72Y/zEvKJBC3U3pzPBDKiPO3sgUNa+0hqtMrTgPG1voepzL/y0eyYAmUKBZZbc FutwHFzF5WZU+oQvcdPlTrZ1r3BzqmVUa+Tiuj3zxXPLuEK0lbWmQregsLYL7cv4di5O dzvan1gbbVe1KTL8kG6/OYCAJ29jquUoeB5cePdDKMWsJwms8dg8O3eg6KaCVGsBryyw TYJg== X-Gm-Message-State: AHPjjUjOdyV2MYmzfXmiZH6a9jv+kWAO3QXkDWY1XaNpFNNRDERZpy6V RiSCLuyk5MDnHbiIKhzgIroBj4HOblfQ X-Google-Smtp-Source: AOwi7QBTyJoQqBPQxJAg5j6CTsAiruhicdk++Cwqj+lQaPUyc+wQ5U/4FTPkzsFyBD1EUnjkjA33S05CzKGK9PWt37E= X-Received: by 10.25.234.220 with SMTP id y89mr621721lfi.188.1504767832521; Thu, 07 Sep 2017 00:03:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.18 with HTTP; Thu, 7 Sep 2017 00:03:51 -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: Thu, 7 Sep 2017 00:03:51 -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: Thu, 07 Sep 2017 07:03:55 -0000 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? zzz, Russ On Wed, Sep 6, 2017 at 5:13 PM, Russell Haley wrote: > On Wed, Sep 6, 2017 at 3:30 PM, Chris Gordon 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 session= s (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=E2=80=9D thinking the CPU was overwhelmed. The system stays= at >90% idle through the entire test (upload and download). I see 2-4% WC= PU 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 a= nd conference through the weekend. If anyone is interested, I=E2=80=99m ha= ppy 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 woul= d 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 ch= ance. >> >>> 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 an= d specific knowledge of what to start poking (of course, this is a great wq= y 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. Any= thing 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