Return-path: Received: from mout02.posteo.de ([185.67.36.142]:41974 "EHLO mout02.posteo.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756249AbcINNmC (ORCPT ); Wed, 14 Sep 2016 09:42:02 -0400 Message-ID: <1473860503.19492.19.camel@embedded.rocks> (sfid-20160914_154206_740371_BF175A50) Subject: Re: TCP data throughput for BCM43362 From: =?ISO-8859-1?Q?J=F6rg?= Krause To: Arend Van Spriel , Franky Lin Cc: Brett Rudley , brcm80211-dev-list , Hante Meuleman , Franky Lin , linux-wireless@vger.kernel.org, Arend van Spriel Date: Wed, 14 Sep 2016 15:41:43 +0200 In-Reply-To: <1472505309.21429.3.camel@embedded.rocks> References: <1470429980.29489.10.camel@embedded.rocks> <1BCE83A1-AA47-438D-BC47-05AE53D40121@embedded.rocks> <1470492734.2120.0.camel@embedded.rocks> <6cdbbae7-8a56-6778-e886-68eeea7add15@broadcom.com> <1471873052.1683.27.camel@embedded.rocks> <40d15186-6ddf-a210-03de-2bbe21957f1d@broadcom.com> <1472505309.21429.3.camel@embedded.rocks> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Sender: linux-wireless-owner@vger.kernel.org List-ID: Hi, On Mon, 2016-08-29 at 23:15 +0200, Jörg Krause wrote: > On Mi, 2016-08-24 at 20:35 +0200, Arend Van Spriel wrote: > > > > On 22-8-2016 15:37, Jörg Krause wrote: > > > > > > > > > Hi all, > > > > > > I am back from vacation and I'd like to do more investigations > > > about > > > this issue. Please see my comments below... > > > > > > On Sun, 2016-08-07 at 13:41 +0200, Arend van Spriel wrote: > > > > > > > > > > > > On 06-08-16 16:12, Jörg Krause wrote: > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > A bit weird email format making it a bit hard to determine > > > > where > > > > your > > > > last reply starts... > > > > > > > > > > > > > > > > > > > > > > > > On Fr, 2016-08-05 at 17:56 -0700, Franky Lin wrote: > > > > > > > > > > On Fri, Aug 5, 2016 at 2:29 PM, Jörg Krause > > > > ed > > > > > ded. > > > > > ro > > > > > cks> > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Am 5. August 2016 23:01:10 MESZ, schrieb Arend Van Spriel < > > > > > arend.vanspriel@broadcom.com>: > > > > > > > > > > > > > > > Op 5 aug. 2016 22:46 schreef "Jörg Krause" > > > > > : > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > I'm using a custom ARM board with an BCM43362 wifi chip from > > > > > > > > > > Broadcom. > > > > > > > > > > > > > > > The wifi chip is attached via SDIO to the controller with a > > > > > clock of > > > > > 48MHz. Linux kernel version is 4.7. > > > > > > > > > > When measuring the network bandwidth with iperf3 I get a > > > > > bandwith of > > > > > only around 5 Mbps. I found a similar thread at the Broadcom > > > > > > > > > > community > > > > > > > > > > > > > > > [1] where the test was done with a M4 CPU + BCM43362 and an > > > > > average > > > > > result of 3.3 Mbps. > > > > > > > > > > Interestingly, a BCM43362 Wi-Fi Dev Kit [2] notes a TCP data > > > > > > > > > > throughput > > > > > > > > > > > > > > > greater than 20 Mbps. > > > > > > > > > > Why is the throughput I measured much lower? Note that I > > > > > measured > > > > > several times with almost no neighbor devices or networks. > > > > > > > > > > This is a test sample measured with iperf3: > > > > > > > > > >     $ iperf3 -c 192.168.2.1 -i 1 -t 10 > > > > >     Connecting to host 192.168.2.1, port 5201 > > > > >     [  4] local 192.168.2.155 port 36442 connected to > > > > > 192.168.2.1 > > > > > > > > > > port > > > > > > > > > > > > > > >     5201 > > > > >     [ ID] > > > > > Interval           Transfer     Bandwidth       Retr  Cwnd > > > > >     [  4]   0.00-1.00   sec   615 KBytes  5.04 > > > > > Mbits/sec    0   56.6 > > > > >     KBytes > > > > >     [  4]   1.00-2.00   sec   622 KBytes  5.10 > > > > > Mbits/sec    0   84.8 > > > > >     KBytes > > > > >     [  4]   2.00-3.00   sec   625 KBytes  5.12 > > > > > Mbits/sec    0    113 > > > > >     KBytes > > > > >     [  4]   3.00-4.00   sec   571 KBytes  4.68 > > > > > Mbits/sec    0    140 > > > > >     KBytes > > > > >     [  4]   4.00-5.00   sec   594 KBytes  4.87 > > > > > Mbits/sec    0    167 > > > > >     KBytes > > > > >     [  4]   5.00-6.00   sec   628 KBytes  5.14 > > > > > Mbits/sec    0    195 > > > > >     KBytes > > > > >     [  4]   6.00-7.00   sec   619 KBytes  5.07 > > > > > Mbits/sec    0    202 > > > > >     KBytes > > > > >     [  4]   7.00-8.00   sec   608 KBytes  4.98 > > > > > Mbits/sec    0    202 > > > > >     KBytes > > > > >     [  4]   8.00-9.00   sec   602 KBytes  4.93 > > > > > Mbits/sec    0    202 > > > > >     KBytes > > > > >     [  4]   9.00-10.00  sec   537 KBytes  4.40 > > > > > Mbits/sec    0    202 > > > > >     KBytes > > > > >     - - - - - - - - - - - - - - - - - - - - - - - - - > > > > >     [ ID] > > > > > Interval           Transfer     Bandwidth       Retr > > > > >     [  4]   0.00-10.00  sec  5.88 MBytes  4.93 > > > > >     Mbits/sec    0             sender > > > > >     [  4]   0.00-10.00  sec  5.68 MBytes  4.76 > > > > >     Mbits/sec                  receiver > > > > > > > > > > > > > > > Not overly familiar with iperf3. Do these lines mean you are > > > > > doing > > > > > bidirectional test, ie. upstream and downstream at the same > > > > > time. > > > > > Another > > > > > thing affecting tput could be power-save. > > > > > > > > > > > > > > > No, iperf3 does not support bidrectional test. Power-save is > > > > > turned > > > > > off. > > > > > > > > > > What does iw link say? > > > > > > > > > > > > > but I guess it starts here! > > > > > > > > > > > > > > > > > > > > > > > > I compared the results with a Cubietruck I have: > > > > > > > > > > # iperf3 -s > > > > > ----------------------------------------------------------- > > > > > Server listening on 5201 > > > > > ----------------------------------------------------------- > > > > > Accepted connection from 192.168.178.46, port 42906 > > > > > [  5] local 192.168.178.38 port 5201 connected to > > > > > 192.168.178.46 > > > > > port > > > > > 42908 > > > > > [ ID] Interval           Transfer     Bandwidth > > > > > [  5]   0.00-1.00   sec  2.29 MBytes  19.2 > > > > > Mbits/sec                   > > > > > [  5]   1.00-2.00   sec  2.21 MBytes  18.5 > > > > > Mbits/sec                   > > > > > [  5]   2.00-3.00   sec  2.17 MBytes  18.2 > > > > > Mbits/sec                   > > > > > [  5]   3.00-4.00   sec  2.09 MBytes  17.6 > > > > > Mbits/sec                   > > > > > [  5]   4.00-5.00   sec  2.20 MBytes  18.5 > > > > > Mbits/sec                   > > > > > [  5]   5.00-6.00   sec  2.64 MBytes  22.1 > > > > > Mbits/sec                   > > > > > [  5]   6.00-7.00   sec  2.67 MBytes  22.4 > > > > > Mbits/sec                   > > > > > [  5]   7.00-8.00   sec  2.62 MBytes  22.0 > > > > > Mbits/sec                   > > > > > [  5]   8.00-9.00   sec  2.35 MBytes  19.8 > > > > > Mbits/sec                   > > > > > [  5]   9.00-10.00  sec  2.30 MBytes  19.3 > > > > > Mbits/sec                   > > > > > [  5]  10.00-10.03  sec  83.4 KBytes  23.5 > > > > > Mbits/sec                   > > > > > - - - - - - - - - - - - - - - - - - - - - - - - - > > > > > [ ID] Interval           Transfer     Bandwidth       Retr > > > > > [  5]   0.00-10.03  sec  23.9 MBytes  20.0 > > > > > Mbits/sec    0             sender > > > > > [  5]   0.00-10.03  sec  23.6 MBytes  19.8 > > > > > Mbits/sec                  receiver > > > > > > > > > > # iw dev wlan0 link > > > > > Connected to xx:xx:xx:xx:xx (on wlan0) > > > > > SSID: xxx > > > > > freq: 2437 > > > > > tx bitrate: 65.0 MBit/s > > > > > > > > > > bss flags: short-preamble short-slot-time > > > > > dtim period: 1 > > > > > beacon int: 100 > > > > > > > > Too bad RSSI is not in the output above. That may be due to a > > > > regression > > > > in our driver which has been fixed by commit 94abd778a7bb > > > > ("brcmfmac: > > > > add fallback for devices that do not report per-chain values"). > > > > However, > > > > the tx bitrate seems within the same range as the other > > > > platform. > > > > > > > > > > > > > > > > > > > > > > > > The Cubietruck works also with the brcmfmac driver. > > > > > > > > > > May it depend on the NVRAM file? > > > > > > > > Not sure. Can you tell me a bit more about the custom ARM > > > > board. > > > > Does > > > > it > > > > use the same wifi module as Cubietruck, ie. the AMPAK AP6210? > > > > If > > > > you > > > > can > > > > make a wireshark sniff we can check the actual bitrate and > > > > medium > > > > density in terms of packets. Another thing to look at is the > > > > SDIO > > > > host > > > > controller. In brcmf_sdiod_sgtable_alloc() some key values are > > > > used > > > > from > > > > the host controller. It only logs the number of entries of the > > > > scatter-gather table, but could you add the other values in > > > > this > > > > function that are used to determine the number of entries. > > > > > > My board uses the BCM43362 chip solely (no Bluetooth) attached to > > > the > > > SDIO interface of a NXP i.MX28 processor. > > > > > > I added some additional printk() to brcmf_sdiod_sgtable_alloc(). > > > These > > > are the values printed after modprobe brcmfmac: > > > > > > [    8.926657] sg_support=1 > > > [    8.929440] max_blocks=511 > > > [    8.932213] max_request_size=261632 > > > [    8.935741] max_segment_count=52 > > > [    8.939005] max_segment_size=65280 > > > [    8.946095] nents=35 > > > > Thanks. That looks good. > > > > > > > > > > > Additionally I attached a xz compresses wireshark sniff while > > > running > > > iper3 between the BCM43362 running as in AP mode with iperf3 as a > > > server and a PC in station mode running iperf3 as a client. > > > > Looking at the sniff it seems you captured on the ethernet side. > > That > > does not give me any 802.11 specific info. Can you make a wireless > > capture preferably without encryption. > > You,re right! Sorry for this mistake. I did a re-capture on the > wireless side now. Anything new about this? Anything I can do to help? Best regards Jörg Krause