Re: TCP data throughput for BCM43362

["Jörg Krause" <joerg.krause@embedded.rocks>]

[-- Attachment #1: Type: text/plain, Size: 7785 bytes --]

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 <joerg.krause@embedded.
> > 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"
> > <joerg.krause@embedded.rocks>:
> > 
> > 
> > 
> > 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

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.

Best regards
Jörg Krause

[-- Attachment #2: bcm43362.pcapng.xz --]
[-- Type: application/x-xz, Size: 190004 bytes --]