On 14-9-2016 15:41, Jörg Krause wrote:
> 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 <joerg.krause@emb
>>>>>> ed
>>>>>> ded.
>>>>>> ro
>>>>>> cks>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Am 5. August 2016 23:01:10 MESZ, schrieb Arend Van Spriel <
>>>>>> arend.vanspriel@xxxxxxxxxxxx>:
>>>>>>
>>>>>>
>>>>>> 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
>>>
>>> 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?
I missed your previous email. Was already wondering whether to ping you.
Digging around in my email folders I found it so will take a look at it.
Regards,
Arend
