On 11-10-2016 8:14, Jörg Krause wrote:
>
>
> Hi Arend,
>
> Am 22. September 2016 16:00:36 MESZ, schrieb Arend Van Spriel <arend.vanspriel@xxxxxxxxxxxx>:
>> Op 22 sep. 2016 14:52 schreef "Jörg Krause"
>> <joerg.krause@embedded.rocks>:
>>>
>>> On Do, 2016-09-22 at 10:09 +0200, Arend Van Spriel wrote:
>>>> On 19-9-2016 8:36, Jörg Krause wrote:
>>>>>
>>>>> Hi Arend,
>>>>>
>>>>> On Wed, 2016-09-14 at 20:13 +0200, Arend Van Spriel wrote:
>>>>>>
>>>>>> 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
>>>>>>>>>>>> Cwn
>>>>>>>>>>>> d
>>>>>>>>>>>> [ 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.
>>>>>
>>>>> Did you had some time to look at this?
>>>>
>>>> Ehm. I still only see TCP stuff. To capture 802.11 management
>> frames
>>>> you
>>>> need preferably a dedicated device using monitor mode [1].
>>>
>>> Stupid me! Now I used a monitor interface on a desktop to monitor the
>>> traffic between the BCM43362 operating in soft-AP mode and a notebook
>>> operating in managed mode.
>>>
>>> The BCM43362 runs the iperf server, the notebook the iperf client.
>>
>> Thanks.
>>
>> Week almost through so might next week.
>
> Did you had some time to look at this?
So the bcm43362 is your AP and running iperf server. What specs does the
ARM on your custom board have? The trace shows that it does not do
aggregation. What it does not show is whether A-MPDU was setup, ie.
ADDBA message exchange. So could you create a similar capture including
connection setup, ie. AUTH/ASSOC, etc.
Just to confirm. You are using the firmware from linux-firmware, right?
Or are you using firmware from the wiced dev kit?
Regards,
Arend
