On 12-10-16 16:27, Jörg Krause wrote:
> On Mi, 2016-10-12 at 10:11 +0200, Arend Van Spriel wrote:
>> On 11-10-2016 8:14, Jörg Krause wrote:
>>>
>>>
>>>
>>> Hi Arend,
>>>
>>> Am 22. September 2016 16:00:36 MESZ, schrieb Arend Van Spriel <aren
>>> d.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.
>
> It is running the iperf server. It is running in station mode as well
> as in AP mode, depending on the use case. The wireshark dump was taken
> when the bcm43362 is operating in AP mode.
>
>> What specs does the ARM on your custom board have?
>
> Which specs do you mean?
>
>> 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.
>
> Yes, I can do that. Note, that I am using wpa_supplicant 2.5 for AP
> mode operation (not hostapd).
ok. unchartered territory for me. In the beacon frame I see
.... ..01 = Maximum Rx A-MPDU Length: 0x1 (16383[Bytes])
...1 10.. = MPDU Density: 8 [usec] (0x6)
In the trace it is only ~1500 bytes so no A-MPDU. What device is in the
notebook? Can you use 'iw list' there to obtain info.
>> Just to confirm. You are using the firmware from linux-firmware,
>> right?
>
> Right.
>
>> Or are you using firmware from the wiced dev kit?
>
> No. I guess you mean bcmdhd?
You referred to 20 Mbps claim on wiced dev kit page at mouser so I
assumed you were using that and it includes firmware. As you confirmed
using firmware from linux-firmware repo this question does not matter.
Regards,
Arend
> Best regards
> Jörg Krause
>
