Return-path: Received: from mail-wm0-f53.google.com ([74.125.82.53]:38670 "EHLO mail-wm0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933142AbcHXSnF (ORCPT ); Wed, 24 Aug 2016 14:43:05 -0400 Received: by mail-wm0-f53.google.com with SMTP id o80so39536757wme.1 for ; Wed, 24 Aug 2016 11:43:05 -0700 (PDT) Subject: Re: TCP data throughput for BCM43362 To: =?UTF-8?Q?J=c3=b6rg_Krause?= , Franky Lin 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> Cc: Brett Rudley , brcm80211-dev-list , Hante Meuleman , Franky Lin , linux-wireless@vger.kernel.org, Arend van Spriel From: Arend Van Spriel Message-ID: <40d15186-6ddf-a210-03de-2bbe21957f1d@broadcom.com> (sfid-20160824_204343_331277_FA664033) Date: Wed, 24 Aug 2016 20:35:40 +0200 MIME-Version: 1.0 In-Reply-To: <1471873052.1683.27.camel@embedded.rocks> Content-Type: text/plain; charset=utf-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: 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 >> 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. Regards, Arend > Best regards > Jörg Krause >