* TCP data throughput for BCM43362
@ 2016-08-05 20:46 Jörg Krause
[not found] ` <CAF7Mx6o+WuQqtzuApMWQ8YAkLSX7xQ_H06xmO--RxFdwHwzLdQ@mail.gmail.com>
0 siblings, 1 reply; 23+ messages in thread
From: Jörg Krause @ 2016-08-05 20:46 UTC (permalink / raw)
To: linux-wireless
Cc: brcm80211-dev-list, Brett Rudley, Arend van Spriel, Franky Lin,
Hante Meuleman
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
[1] https://community.broadcom.com/thread/3978
[2] http://www.mouser.de/new/broadcom/broadcom-bcm943362wcd4/
Best regards
Jörg Krause
^ permalink raw reply [flat|nested] 23+ messages in thread[parent not found: <CAF7Mx6o+WuQqtzuApMWQ8YAkLSX7xQ_H06xmO--RxFdwHwzLdQ@mail.gmail.com>]
* Re: TCP data throughput for BCM43362 [not found] ` <CAF7Mx6o+WuQqtzuApMWQ8YAkLSX7xQ_H06xmO--RxFdwHwzLdQ@mail.gmail.com> @ 2016-08-05 21:29 ` Jörg Krause [not found] ` <CA+8PC_f7VQMwBfQmZZ_vUtYtNJKVYzmFmxziAwoG8-iRUeW9Jw@mail.gmail.com> 0 siblings, 1 reply; 23+ messages in thread From: Jörg Krause @ 2016-08-05 21:29 UTC (permalink / raw) To: Arend Van Spriel Cc: Brett Rudley, brcm80211-dev-list, Hante Meuleman, Franky Lin, linux-wireless, Arend van Spriel 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <CA+8PC_f7VQMwBfQmZZ_vUtYtNJKVYzmFmxziAwoG8-iRUeW9Jw@mail.gmail.com>]
* Re: TCP data throughput for BCM43362 [not found] ` <CA+8PC_f7VQMwBfQmZZ_vUtYtNJKVYzmFmxziAwoG8-iRUeW9Jw@mail.gmail.com> @ 2016-08-06 8:07 ` Jörg Krause 2016-08-06 14:12 ` Jörg Krause 1 sibling, 0 replies; 23+ messages in thread From: Jörg Krause @ 2016-08-06 8:07 UTC (permalink / raw) To: Franky Lin Cc: Arend Van Spriel, Brett Rudley, brcm80211-dev-list, Hante Meuleman, Franky Lin, linux-wireless, Arend van Spriel Hi Franky, 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? It says: # iw dev wlan0 link Connected to xx:xx:xx:xx:xx (on wlan0) SSID: xxx freq: 2437 signal: -60 dBm tx bitrate: 58.5 MBit/s bss flags: short-preamble short-slot-time dtim period: 1 beacon int: 100 Best regards Jörg Krause ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: TCP data throughput for BCM43362 [not found] ` <CA+8PC_f7VQMwBfQmZZ_vUtYtNJKVYzmFmxziAwoG8-iRUeW9Jw@mail.gmail.com> 2016-08-06 8:07 ` Jörg Krause @ 2016-08-06 14:12 ` Jörg Krause 2016-08-07 11:41 ` Arend van Spriel 1 sibling, 1 reply; 23+ messages in thread From: Jörg Krause @ 2016-08-06 14:12 UTC (permalink / raw) To: Franky Lin Cc: Arend Van Spriel, Brett Rudley, brcm80211-dev-list, Hante Meuleman, Franky Lin, linux-wireless, Arend van Spriel Hi all, 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? 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 The Cubietruck works also with the brcmfmac driver. May it depend on the NVRAM file? Best regards Jörg Krause ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: TCP data throughput for BCM43362 2016-08-06 14:12 ` Jörg Krause @ 2016-08-07 11:41 ` Arend van Spriel 2016-08-12 9:25 ` Jörg Krause 2016-08-22 13:37 ` Jörg Krause 0 siblings, 2 replies; 23+ messages in thread From: Arend van Spriel @ 2016-08-07 11:41 UTC (permalink / raw) To: Jörg Krause, Franky Lin Cc: Brett Rudley, brcm80211-dev-list, Hante Meuleman, Franky Lin, linux-wireless, Arend van Spriel 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. Regards, Arend ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: TCP data throughput for BCM43362 2016-08-07 11:41 ` Arend van Spriel @ 2016-08-12 9:25 ` Jörg Krause 2016-08-22 13:37 ` Jörg Krause 1 sibling, 0 replies; 23+ messages in thread From: Jörg Krause @ 2016-08-12 9:25 UTC (permalink / raw) To: Arend van Spriel, Franky Lin Cc: Brett Rudley, brcm80211-dev-list, Hante Meuleman, Franky Lin, linux-wireless, Arend van Spriel, Jörg Krause Am 7. August 2016 13:41:04 MESZ, schrieb Arend van Spriel <arend.vanspriel@broadcom.com>: >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... Sorry for my bad mobile mail client. I hope this one can handle in line comments. > >> 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. Many thanks for your conclusions! I am on vacation right now and I will investigate this issue further when I am back. Best regards, Jörg Krause ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: TCP data throughput for BCM43362 2016-08-07 11:41 ` Arend van Spriel 2016-08-12 9:25 ` Jörg Krause @ 2016-08-22 13:37 ` Jörg Krause 2016-08-24 18:35 ` Arend Van Spriel 1 sibling, 1 reply; 23+ messages in thread From: Jörg Krause @ 2016-08-22 13:37 UTC (permalink / raw) To: Arend van Spriel, Franky Lin Cc: Brett Rudley, brcm80211-dev-list, Hante Meuleman, Franky Lin, linux-wireless, Arend van Spriel [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: TCP data throughput for BCM43362 2016-08-22 13:37 ` Jörg Krause @ 2016-08-24 18:35 ` Arend Van Spriel 2016-08-29 21:15 ` Jörg Krause 0 siblings, 1 reply; 23+ messages in thread From: Arend Van Spriel @ 2016-08-24 18:35 UTC (permalink / raw) To: Jörg Krause, Franky Lin Cc: Brett Rudley, brcm80211-dev-list, Hante Meuleman, Franky Lin, linux-wireless, Arend van Spriel 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@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 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 > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: TCP data throughput for BCM43362 2016-08-24 18:35 ` Arend Van Spriel @ 2016-08-29 21:15 ` Jörg Krause 2016-09-14 13:41 ` Jörg Krause 0 siblings, 1 reply; 23+ messages in thread From: Jörg Krause @ 2016-08-29 21:15 UTC (permalink / raw) To: Arend Van Spriel, Franky Lin Cc: Brett Rudley, brcm80211-dev-list, Hante Meuleman, Franky Lin, linux-wireless, Arend van Spriel [-- Attachment #1: Type: text/plain, Size: 9212 bytes --] 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@embed > > > > ded. > > > > 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 > > 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. Best regards Jörg Krause [-- Attachment #2: bcm43362.pcapng.xz --] [-- Type: application/x-xz, Size: 201228 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: TCP data throughput for BCM43362 2016-08-29 21:15 ` Jörg Krause @ 2016-09-14 13:41 ` Jörg Krause 2016-09-14 18:13 ` Arend Van Spriel 0 siblings, 1 reply; 23+ messages in thread From: Jörg Krause @ 2016-09-14 13:41 UTC (permalink / raw) To: Arend Van Spriel, Franky Lin Cc: Brett Rudley, brcm80211-dev-list, Hante Meuleman, Franky Lin, linux-wireless, Arend van Spriel 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@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 > > > > 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? Best regards Jörg Krause ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: TCP data throughput for BCM43362 2016-09-14 13:41 ` Jörg Krause @ 2016-09-14 18:13 ` Arend Van Spriel 2016-09-19 6:36 ` Jörg Krause 0 siblings, 1 reply; 23+ messages in thread From: Arend Van Spriel @ 2016-09-14 18:13 UTC (permalink / raw) To: Jörg Krause, Franky Lin Cc: Brett Rudley, brcm80211-dev-list, Hante Meuleman, Franky Lin, linux-wireless, Arend van Spriel 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@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 >>> >>> 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: TCP data throughput for BCM43362 2016-09-14 18:13 ` Arend Van Spriel @ 2016-09-19 6:36 ` Jörg Krause 2016-09-21 14:15 ` Arend van Spriel 2016-09-22 8:09 ` Arend Van Spriel 0 siblings, 2 replies; 23+ messages in thread From: Jörg Krause @ 2016-09-19 6:36 UTC (permalink / raw) To: Arend Van Spriel, Franky Lin Cc: Brett Rudley, brcm80211-dev-list, Hante Meuleman, Franky Lin, linux-wireless, Arend van Spriel 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@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 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? Best regards Jörg Krause ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: TCP data throughput for BCM43362 2016-09-19 6:36 ` Jörg Krause @ 2016-09-21 14:15 ` Arend van Spriel 2016-09-22 8:09 ` Arend Van Spriel 1 sibling, 0 replies; 23+ messages in thread From: Arend van Spriel @ 2016-09-21 14:15 UTC (permalink / raw) To: Jörg Krause, Franky Lin Cc: Brett Rudley, brcm80211-dev-list, Hante Meuleman, Franky Lin, linux-wireless, Arend van Spriel On 19-09-16 08: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@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 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? Sorry for the delay, but I am kinda swamped. Will try spent some time on it later this week. Regards, Arend ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: TCP data throughput for BCM43362 2016-09-19 6:36 ` Jörg Krause 2016-09-21 14:15 ` Arend van Spriel @ 2016-09-22 8:09 ` Arend Van Spriel 2016-09-22 12:52 ` Jörg Krause 1 sibling, 1 reply; 23+ messages in thread From: Arend Van Spriel @ 2016-09-22 8:09 UTC (permalink / raw) To: Jörg Krause, Franky Lin Cc: Brett Rudley, brcm80211-dev-list, Hante Meuleman, Franky Lin, linux-wireless, Arend van Spriel 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@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 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]. Regards, Arend [1] https://wireless.wiki.kernel.org/en/users/documentation/modes#monitor_mode ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: TCP data throughput for BCM43362 2016-09-22 8:09 ` Arend Van Spriel @ 2016-09-22 12:52 ` Jörg Krause [not found] ` <CAF7Mx6q+B4RoURNF5XxewjF9aVGCXg==XU0aDD6w+354yXZ70Q@mail.gmail.com> 0 siblings, 1 reply; 23+ messages in thread From: Jörg Krause @ 2016-09-22 12:52 UTC (permalink / raw) To: Arend Van Spriel, Franky Lin Cc: Brett Rudley, brcm80211-dev-list, Hante Meuleman, Franky Lin, linux-wireless, Arend van Spriel [-- Attachment #1: Type: text/plain, Size: 14340 bytes --] 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@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 > > > > > > > > > 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. Best regards Jörg Krause [-- Attachment #2: bcm43362.pcapng.xz --] [-- Type: application/x-xz, Size: 590240 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <CAF7Mx6q+B4RoURNF5XxewjF9aVGCXg==XU0aDD6w+354yXZ70Q@mail.gmail.com>]
* Re: TCP data throughput for BCM43362 [not found] ` <CAF7Mx6q+B4RoURNF5XxewjF9aVGCXg==XU0aDD6w+354yXZ70Q@mail.gmail.com> @ 2016-10-11 6:14 ` Jörg Krause 2016-10-12 8:11 ` Arend Van Spriel 0 siblings, 1 reply; 23+ messages in thread From: Jörg Krause @ 2016-10-11 6:14 UTC (permalink / raw) To: Arend Van Spriel Cc: brcm80211-dev-list, Brett Rudley, Franky Lin, Hante Meuleman, linux-wireless, Franky Lin, Arend van Spriel Hi Arend, Am 22. September 2016 16:00:36 MESZ, schrieb Arend Van Spriel <arend.vanspriel@broadcom.com>: >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@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 >> > > > > > > > > > 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? Best regards Jörg Krause -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: TCP data throughput for BCM43362 2016-10-11 6:14 ` Jörg Krause @ 2016-10-12 8:11 ` Arend Van Spriel 2016-10-12 14:27 ` Jörg Krause 0 siblings, 1 reply; 23+ messages in thread From: Arend Van Spriel @ 2016-10-12 8:11 UTC (permalink / raw) To: Jörg Krause Cc: brcm80211-dev-list, Brett Rudley, Franky Lin, Hante Meuleman, linux-wireless, Franky Lin, Arend van Spriel 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@broadcom.com>: >> 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@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 >>>>>>>>>>>> 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: TCP data throughput for BCM43362 2016-10-12 8:11 ` Arend Van Spriel @ 2016-10-12 14:27 ` Jörg Krause 2016-10-12 19:08 ` Arend van Spriel 0 siblings, 1 reply; 23+ messages in thread From: Jörg Krause @ 2016-10-12 14:27 UTC (permalink / raw) To: Arend Van Spriel Cc: brcm80211-dev-list, Brett Rudley, Franky Lin, Hante Meuleman, linux-wireless, Franky Lin, Arend van Spriel 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@broadcom.com>: > > > > > > 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@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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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). > 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? Best regards Jörg Krause ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: TCP data throughput for BCM43362 2016-10-12 14:27 ` Jörg Krause @ 2016-10-12 19:08 ` Arend van Spriel 2016-10-12 19:30 ` Jörg Krause 2016-10-12 20:48 ` Jörg Krause 0 siblings, 2 replies; 23+ messages in thread From: Arend van Spriel @ 2016-10-12 19:08 UTC (permalink / raw) To: Jörg Krause Cc: brcm80211-dev-list, Brett Rudley, Franky Lin, Hante Meuleman, linux-wireless, Franky Lin, Arend van Spriel 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@broadcom.com>: >>>> >>>> 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@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 >>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 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 > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: TCP data throughput for BCM43362 2016-10-12 19:08 ` Arend van Spriel @ 2016-10-12 19:30 ` Jörg Krause [not found] ` <CAF7Mx6rqfbhDL-MRZ93vzCdSskgqi_bVNn=1SGb_WKV=DZZ+YQ@mail.gmail.com> 2016-10-12 20:48 ` Jörg Krause 1 sibling, 1 reply; 23+ messages in thread From: Jörg Krause @ 2016-10-12 19:30 UTC (permalink / raw) To: Arend van Spriel Cc: brcm80211-dev-list, Brett Rudley, Franky Lin, Hante Meuleman, linux-wireless, Franky Lin, Arend van Spriel On Mi, 2016-10-12 at 21:08 +0200, Arend van Spriel wrote: [snip] > On 12-10-16 16:27, Jörg Krause wrote: > > > > 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. The issue is not only valid for operating the BCM43362 in AP mode, but also in station mode. The TCP throughput is the same for both modes. > What device is in the notebook? It is a Broadcom 43225. However, the low TCP throughput is not specific to this device but with all kind of devices including Smartphones, Notebooks, PCs running the iperf client. > Can you use 'iw list' there to obtain info. $ iw list Wiphy phy0 max # scan SSIDs: 4 max scan IEs length: 2257 bytes max # sched scan SSIDs: 0 max # match sets: 0 max # scan plans: 1 max scan plan interval: -1 max scan plan iterations: 0 Retry short limit: 7 Retry long limit: 4 Coverage class: 0 (up to 0m) Device supports RSN-IBSS. Supported Ciphers: * WEP40 (00-0f-ac:1) * WEP104 (00-0f-ac:5) * TKIP (00-0f-ac:2) * CCMP (00-0f-ac:4) * 00-0f-ac:10 * GCMP (00-0f-ac:8) * 00-0f-ac:9 Available Antennas: TX 0 RX 0 Supported interface modes: * IBSS * managed * AP * AP/VLAN * monitor Band 1: Capabilities: 0x70 HT20 Static SM Power Save RX Greenfield RX HT20 SGI RX HT40 SGI No RX STBC Max AMSDU length: 3839 bytes No DSSS/CCK HT40 Maximum RX AMPDU length 65535 bytes (exponent: 0x003) Minimum RX AMPDU time spacing: 8 usec (0x06) HT Max RX data rate: 500 Mbps HT TX/RX MCS rate indexes supported: 0-15 Bitrates (non-HT): * 1.0 Mbps * 2.0 Mbps (short preamble supported) * 5.5 Mbps (short preamble supported) * 11.0 Mbps (short preamble supported) * 6.0 Mbps * 9.0 Mbps * 12.0 Mbps * 18.0 Mbps * 24.0 Mbps * 36.0 Mbps * 48.0 Mbps * 54.0 Mbps Frequencies: * 2412 MHz [1] (19.0 dBm) * 2417 MHz [2] (19.0 dBm) * 2422 MHz [3] (19.0 dBm) * 2427 MHz [4] (19.0 dBm) * 2432 MHz [5] (19.0 dBm) * 2437 MHz [6] (19.0 dBm) * 2442 MHz [7] (19.0 dBm) * 2447 MHz [8] (19.0 dBm) * 2452 MHz [9] (19.0 dBm) * 2457 MHz [10] (19.0 dBm) * 2462 MHz [11] (19.0 dBm) * 2467 MHz [12] (19.0 dBm) (no IR) * 2472 MHz [13] (19.0 dBm) (no IR) * 2484 MHz [14] (disabled) Supported commands: * new_interface * set_interface * new_key * start_ap * new_station * new_mpath * set_mesh_config * set_bss * authenticate * associate * deauthenticate * disassociate * join_ibss * join_mesh * set_tx_bitrate_mask * frame * frame_wait_cancel * set_wiphy_netns * set_channel * set_wds_peer * probe_client * set_noack_map * register_beacons * start_p2p_device * set_mcast_rate * set_qos_map * connect * disconnect Supported TX frame types: * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * mesh point: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 Supported RX frame types: * IBSS: 0x40 0xb0 0xc0 0xd0 * managed: 0x40 0xd0 * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0 * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0 * mesh point: 0xb0 0xc0 0xd0 * P2P-client: 0x40 0xd0 * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0 * P2P-device: 0x40 0xd0 software interface modes (can always be added): * AP/VLAN * monitor interface combinations are not supported HT Capability overrides: * MCS: ff ff ff ff ff ff ff ff ff ff * maximum A-MSDU length * supported channel width * short GI for 40 MHz * max A-MPDU length exponent * min MPDU start spacing Device supports TX status socket option. Device supports HT-IBSS. Device supports SAE with AUTHENTICATE command Device supports low priority scan. Device supports scan flush. Device supports AP scan. Device supports per-vif TX power setting Driver supports a userspace MPM Device supports configuring vdev MAC-addr on create. > > > > > > > > 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. I see! Note, that I measured >20MB throughput on the Cubietruck, which is using the AP6210, but also the brcmfmac driver. Best regards Jörg Krause ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <CAF7Mx6rqfbhDL-MRZ93vzCdSskgqi_bVNn=1SGb_WKV=DZZ+YQ@mail.gmail.com>]
* Re: TCP data throughput for BCM43362 [not found] ` <CAF7Mx6rqfbhDL-MRZ93vzCdSskgqi_bVNn=1SGb_WKV=DZZ+YQ@mail.gmail.com> @ 2016-10-12 21:19 ` Jörg Krause [not found] ` <CAF7Mx6pD5VZ57PHy5DSj8yLOLY4vir2JhEdEL8SB3kr91OqFsQ@mail.gmail.com> 0 siblings, 1 reply; 23+ messages in thread From: Jörg Krause @ 2016-10-12 21:19 UTC (permalink / raw) To: Arend Van Spriel Cc: Franky Lin, Brett Rudley, brcm80211-dev-list, Hante Meuleman, Franky Lin, linux-wireless, Arend van Spriel On Wed, 2016-10-12 at 23:08 +0200, Arend Van Spriel wrote: > Op 12 okt. 2016 21:30 schreef "Jörg Krause" <joerg.krause@embedded.ro > cks>: > > > > On Mi, 2016-10-12 at 21:08 +0200, Arend van Spriel wrote: > > > > [snip] > > > > > On 12-10-16 16:27, Jörg Krause wrote: > > > > > > > > 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. > > > > The issue is not only valid for operating the BCM43362 in AP mode, > > but > > also in station mode. The TCP throughput is the same for both > > modes. > > > > > What device is in the notebook? > > > > It is a Broadcom 43225. However, the low TCP throughput is not > > specific > > to this device but with all kind of devices including Smartphones, > > Notebooks, PCs running the iperf client. > > > > > Can you use 'iw list' there to obtain info. > > > > $ iw list > > Wiphy phy0 > > max # scan SSIDs: 4 > > max scan IEs length: 2257 bytes > > max # sched scan SSIDs: 0 > > max # match sets: 0 > > max # scan plans: 1 > > max scan plan interval: -1 > > max scan plan iterations: 0 > > Retry short limit: 7 > > Retry long limit: 4 > > Coverage class: 0 (up to 0m) > > Device supports RSN-IBSS. > > Supported Ciphers: > > * WEP40 (00-0f-ac:1) > > * WEP104 (00-0f-ac:5) > > * TKIP (00-0f-ac:2) > > * CCMP (00-0f-ac:4) > > * 00-0f-ac:10 > > * GCMP (00-0f-ac:8) > > * 00-0f-ac:9 > > Available Antennas: TX 0 RX 0 > > Supported interface modes: > > * IBSS > > * managed > > * AP > > * AP/VLAN > > * monitor > > Band 1: > > Capabilities: 0x70 > > HT20 > > Static SM Power Save > > RX Greenfield > > RX HT20 SGI > > RX HT40 SGI > > No RX STBC > > Max AMSDU length: 3839 bytes > > No DSSS/CCK HT40 > > Maximum RX AMPDU length 65535 bytes (exponent: > > 0x003) > > Minimum RX AMPDU time spacing: 8 usec (0x06) > > HT Max RX data rate: 500 Mbps > > HT TX/RX MCS rate indexes supported: 0-15 > > Bitrates (non-HT): > > * 1.0 Mbps > > * 2.0 Mbps (short preamble supported) > > * 5.5 Mbps (short preamble supported) > > * 11.0 Mbps (short preamble supported) > > * 6.0 Mbps > > * 9.0 Mbps > > * 12.0 Mbps > > * 18.0 Mbps > > * 24.0 Mbps > > * 36.0 Mbps > > * 48.0 Mbps > > * 54.0 Mbps > > Frequencies: > > * 2412 MHz [1] (19.0 dBm) > > * 2417 MHz [2] (19.0 dBm) > > * 2422 MHz [3] (19.0 dBm) > > * 2427 MHz [4] (19.0 dBm) > > * 2432 MHz [5] (19.0 dBm) > > * 2437 MHz [6] (19.0 dBm) > > * 2442 MHz [7] (19.0 dBm) > > * 2447 MHz [8] (19.0 dBm) > > * 2452 MHz [9] (19.0 dBm) > > * 2457 MHz [10] (19.0 dBm) > > * 2462 MHz [11] (19.0 dBm) > > * 2467 MHz [12] (19.0 dBm) (no IR) > > * 2472 MHz [13] (19.0 dBm) (no IR) > > * 2484 MHz [14] (disabled) > > Supported commands: > > * new_interface > > * set_interface > > * new_key > > * start_ap > > * new_station > > * new_mpath > > * set_mesh_config > > * set_bss > > * authenticate > > * associate > > * deauthenticate > > * disassociate > > * join_ibss > > * join_mesh > > * set_tx_bitrate_mask > > * frame > > * frame_wait_cancel > > * set_wiphy_netns > > * set_channel > > * set_wds_peer > > * probe_client > > * set_noack_map > > * register_beacons > > * start_p2p_device > > * set_mcast_rate > > * set_qos_map > > * connect > > * disconnect > > Supported TX frame types: > > * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 > > 0x70 0x80 > > 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 > > * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 > > 0x70 > > 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 > > * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 > > 0x80 > > 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 > > * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 > > 0x70 > > 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 > > * mesh point: 0x00 0x10 0x20 0x30 0x40 0x50 > > 0x60 0x70 > > 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 > > * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 > > 0x60 0x70 > > 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 > > * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 > > 0x70 > > 0x80 > > 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 > > * P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 > > 0x60 0x70 > > 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 > > Supported RX frame types: > > * IBSS: 0x40 0xb0 0xc0 0xd0 > > * managed: 0x40 0xd0 > > * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0 > > * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0 > > * mesh point: 0xb0 0xc0 0xd0 > > * P2P-client: 0x40 0xd0 > > * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0 > > * P2P-device: 0x40 0xd0 > > software interface modes (can always be added): > > * AP/VLAN > > * monitor > > interface combinations are not supported > > HT Capability overrides: > > * MCS: ff ff ff ff ff ff ff ff ff ff > > * maximum A-MSDU length > > * supported channel width > > * short GI for 40 MHz > > * max A-MPDU length exponent > > * min MPDU start spacing > > Device supports TX status socket option. > > Device supports HT-IBSS. > > Device supports SAE with AUTHENTICATE command > > Device supports low priority scan. > > Device supports scan flush. > > Device supports AP scan. > > Device supports per-vif TX power setting > > Driver supports a userspace MPM > > Device supports configuring vdev MAC-addr on create. > > > > > > > > > > > > > > > > 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. > > > > I see! Note, that I measured >20MB throughput on the Cubietruck, > > which > > is using the AP6210, but also the brcmfmac driver. > > So does your custom ARM board have an Ethernet socket, ie. run iperf > server > on another device hooked up to the AP over Ethernet. Yes, it does have Ethernet. I hope that I have understand you correctly, so I run an iperf server an my PC and on my ARM board the iperf client. Both devices are connected via Ethernet to the Router (using a Powerline adaptor): # iperf3 -c 192.168.178.41 -i 1 -t 10 Connecting to host 192.168.178.41, port 5201 [ 4] local 192.168.178.40 port 36130 connected to 192.168.178.41 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.09 sec 2.50 MBytes 19.2 Mbits/sec 0 14.1 KBytes [ 4] 1.09-2.21 sec 2.50 MBytes 18.8 Mbits/sec 0 14.1 KBytes [ 4] 2.21-3.30 sec 2.50 MBytes 19.2 Mbits/sec 0 14.1 KBytes [ 4] 3.30-4.39 sec 2.50 MBytes 19.3 Mbits/sec 0 14.1 KBytes [ 4] 4.39-5.48 sec 2.50 MBytes 19.2 Mbits/sec 0 14.1 KBytes [ 4] 5.48-6.02 sec 1.25 MBytes 19.3 Mbits/sec 0 14.1 KBytes [ 4] 6.02-7.11 sec 2.50 MBytes 19.3 Mbits/sec 0 14.1 KBytes [ 4] 7.11-8.20 sec 2.50 MBytes 19.3 Mbits/sec 0 14.1 KBytes [ 4] 8.20-9.43 sec 2.50 MBytes 17.1 Mbits/sec 0 14.1 KBytes [ 4] 9.43-10.51 sec 2.50 MBytes 19.4 Mbits/sec 0 14.1 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.51 sec 23.8 MBytes 19.0 Mbits/sec 0 sender [ 4] 0.00-10.51 sec 23.8 MBytes 19.0 Mbits/sec receiver iperf Done. Best regards Jörg Krause ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <CAF7Mx6pD5VZ57PHy5DSj8yLOLY4vir2JhEdEL8SB3kr91OqFsQ@mail.gmail.com>]
* Re: TCP data throughput for BCM43362 [not found] ` <CAF7Mx6pD5VZ57PHy5DSj8yLOLY4vir2JhEdEL8SB3kr91OqFsQ@mail.gmail.com> @ 2016-10-12 22:50 ` Jörg Krause 0 siblings, 0 replies; 23+ messages in thread From: Jörg Krause @ 2016-10-12 22:50 UTC (permalink / raw) To: Arend Van Spriel Cc: brcm80211-dev-list, Brett Rudley, Franky Lin, Hante Meuleman, linux-wireless, Franky Lin, Arend van Spriel On Thu, 2016-10-13 at 00:25 +0200, Arend Van Spriel wrote: > Op 12 okt. 2016 23:19 schreef "Jörg Krause" <joerg.krause@embedded.ro > cks>: > > > > On Wed, 2016-10-12 at 23:08 +0200, Arend Van Spriel wrote: > > > Op 12 okt. 2016 21:30 schreef "Jörg Krause" <joerg.krause@embedde > > > d.ro > > > cks>: > > > > > > > > On Mi, 2016-10-12 at 21:08 +0200, Arend van Spriel wrote: > > > > > > > > [snip] > > > > > > > > > On 12-10-16 16:27, Jörg Krause wrote: > > > > > > > > > > > > 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. > > > > > > > > The issue is not only valid for operating the BCM43362 in AP > > > > mode, > > > > but > > > > also in station mode. The TCP throughput is the same for both > > > > modes. > > > > > > > > > What device is in the notebook? > > > > > > > > It is a Broadcom 43225. However, the low TCP throughput is not > > > > specific > > > > to this device but with all kind of devices including > > > > Smartphones, > > > > Notebooks, PCs running the iperf client. > > > > > > > > > Can you use 'iw list' there to obtain info. > > > > > > > > $ iw list > > > > Wiphy phy0 > > > > max # scan SSIDs: 4 > > > > max scan IEs length: 2257 bytes > > > > max # sched scan SSIDs: 0 > > > > max # match sets: 0 > > > > max # scan plans: 1 > > > > max scan plan interval: -1 > > > > max scan plan iterations: 0 > > > > Retry short limit: 7 > > > > Retry long limit: 4 > > > > Coverage class: 0 (up to 0m) > > > > Device supports RSN-IBSS. > > > > Supported Ciphers: > > > > * WEP40 (00-0f-ac:1) > > > > * WEP104 (00-0f-ac:5) > > > > * TKIP (00-0f-ac:2) > > > > * CCMP (00-0f-ac:4) > > > > * 00-0f-ac:10 > > > > * GCMP (00-0f-ac:8) > > > > * 00-0f-ac:9 > > > > Available Antennas: TX 0 RX 0 > > > > Supported interface modes: > > > > * IBSS > > > > * managed > > > > * AP > > > > * AP/VLAN > > > > * monitor > > > > Band 1: > > > > Capabilities: 0x70 > > > > HT20 > > > > Static SM Power Save > > > > RX Greenfield > > > > RX HT20 SGI > > > > RX HT40 SGI > > > > No RX STBC > > > > Max AMSDU length: 3839 bytes > > > > No DSSS/CCK HT40 > > > > Maximum RX AMPDU length 65535 bytes > > > > (exponent: > > > > 0x003) > > > > Minimum RX AMPDU time spacing: 8 usec > > > > (0x06) > > > > HT Max RX data rate: 500 Mbps > > > > HT TX/RX MCS rate indexes supported: 0-15 > > > > Bitrates (non-HT): > > > > * 1.0 Mbps > > > > * 2.0 Mbps (short preamble > > > > supported) > > > > * 5.5 Mbps (short preamble > > > > supported) > > > > * 11.0 Mbps (short preamble > > > > supported) > > > > * 6.0 Mbps > > > > * 9.0 Mbps > > > > * 12.0 Mbps > > > > * 18.0 Mbps > > > > * 24.0 Mbps > > > > * 36.0 Mbps > > > > * 48.0 Mbps > > > > * 54.0 Mbps > > > > Frequencies: > > > > * 2412 MHz [1] (19.0 dBm) > > > > * 2417 MHz [2] (19.0 dBm) > > > > * 2422 MHz [3] (19.0 dBm) > > > > * 2427 MHz [4] (19.0 dBm) > > > > * 2432 MHz [5] (19.0 dBm) > > > > * 2437 MHz [6] (19.0 dBm) > > > > * 2442 MHz [7] (19.0 dBm) > > > > * 2447 MHz [8] (19.0 dBm) > > > > * 2452 MHz [9] (19.0 dBm) > > > > * 2457 MHz [10] (19.0 dBm) > > > > * 2462 MHz [11] (19.0 dBm) > > > > * 2467 MHz [12] (19.0 dBm) (no IR) > > > > * 2472 MHz [13] (19.0 dBm) (no IR) > > > > * 2484 MHz [14] (disabled) > > > > Supported commands: > > > > * new_interface > > > > * set_interface > > > > * new_key > > > > * start_ap > > > > * new_station > > > > * new_mpath > > > > * set_mesh_config > > > > * set_bss > > > > * authenticate > > > > * associate > > > > * deauthenticate > > > > * disassociate > > > > * join_ibss > > > > * join_mesh > > > > * set_tx_bitrate_mask > > > > * frame > > > > * frame_wait_cancel > > > > * set_wiphy_netns > > > > * set_channel > > > > * set_wds_peer > > > > * probe_client > > > > * set_noack_map > > > > * register_beacons > > > > * start_p2p_device > > > > * set_mcast_rate > > > > * set_qos_map > > > > * connect > > > > * disconnect > > > > Supported TX frame types: > > > > * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 > > > > 0x70 0x80 > > > > 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 > > > > * managed: 0x00 0x10 0x20 0x30 0x40 0x50 > > > > 0x60 > > > > 0x70 > > > > 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 > > > > * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 > > > > 0x70 > > > > 0x80 > > > > 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 > > > > * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 > > > > 0x60 > > > > 0x70 > > > > 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 > > > > * mesh point: 0x00 0x10 0x20 0x30 0x40 > > > > 0x50 > > > > 0x60 0x70 > > > > 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 > > > > * P2P-client: 0x00 0x10 0x20 0x30 0x40 > > > > 0x50 > > > > 0x60 0x70 > > > > 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 > > > > * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 > > > > 0x60 > > > > 0x70 > > > > > > 0x80 > > > > 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 > > > > * P2P-device: 0x00 0x10 0x20 0x30 0x40 > > > > 0x50 > > > > 0x60 0x70 > > > > 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 > > > > Supported RX frame types: > > > > * IBSS: 0x40 0xb0 0xc0 0xd0 > > > > * managed: 0x40 0xd0 > > > > * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0 > > > > * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 > > > > 0xd0 > > > > * mesh point: 0xb0 0xc0 0xd0 > > > > * P2P-client: 0x40 0xd0 > > > > * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 > > > > 0xd0 > > > > * P2P-device: 0x40 0xd0 > > > > software interface modes (can always be added): > > > > * AP/VLAN > > > > * monitor > > > > interface combinations are not supported > > > > HT Capability overrides: > > > > * MCS: ff ff ff ff ff ff ff ff ff ff > > > > * maximum A-MSDU length > > > > * supported channel width > > > > * short GI for 40 MHz > > > > * max A-MPDU length exponent > > > > * min MPDU start spacing > > > > Device supports TX status socket option. > > > > Device supports HT-IBSS. > > > > Device supports SAE with AUTHENTICATE command > > > > Device supports low priority scan. > > > > Device supports scan flush. > > > > Device supports AP scan. > > > > Device supports per-vif TX power setting > > > > Driver supports a userspace MPM > > > > Device supports configuring vdev MAC-addr on > > > > create. > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > I see! Note, that I measured >20MB throughput on the > > > > Cubietruck, > > > > which > > > > is using the AP6210, but also the brcmfmac driver. > > > > > > So does your custom ARM board have an Ethernet socket, ie. run > > > iperf > > > server > > > on another device hooked up to the AP over Ethernet. > > > > Yes, it does have Ethernet. I hope that I have understand you > > correctly, so I run an iperf server an my PC and on my ARM board > > the > > iperf client. Both devices are connected via Ethernet to the Router > > (using a Powerline adaptor): > > > > # iperf3 -c 192.168.178.41 -i 1 -t 10 > > Connecting to host 192.168.178.41, port 5201 > > [ 4] local 192.168.178.40 port 36130 connected to 192.168.178.41 > > port > > 5201 > > [ ID] Interval Transfer Bandwidth Retr Cwnd > > [ 4] 0.00-1.09 sec 2.50 MBytes 19.2 Mbits/sec 0 14.1 > > KBytes > > [ 4] 1.09-2.21 sec 2.50 MBytes 18.8 Mbits/sec 0 14.1 > > KBytes > > [ 4] 2.21-3.30 sec 2.50 MBytes 19.2 Mbits/sec 0 14.1 > > KBytes > > [ 4] 3.30-4.39 sec 2.50 MBytes 19.3 Mbits/sec 0 14.1 > > KBytes > > [ 4] 4.39-5.48 sec 2.50 MBytes 19.2 Mbits/sec 0 14.1 > > KBytes > > [ 4] 5.48-6.02 sec 1.25 MBytes 19.3 Mbits/sec 0 14.1 > > KBytes > > [ 4] 6.02-7.11 sec 2.50 MBytes 19.3 Mbits/sec 0 14.1 > > KBytes > > [ 4] 7.11-8.20 sec 2.50 MBytes 19.3 Mbits/sec 0 14.1 > > KBytes > > [ 4] 8.20-9.43 sec 2.50 MBytes 17.1 Mbits/sec 0 14.1 > > KBytes > > [ 4] 9.43-10.51 sec 2.50 MBytes 19.4 Mbits/sec 0 14.1 > > KBytes > > - - - - - - - - - - - - - - - - - - - - - - - - - > > [ ID] Interval Transfer Bandwidth Retr > > [ 4] 0.00-10.51 sec 23.8 MBytes 19.0 > > Mbits/sec 0 sender > > [ 4] 0.00-10.51 sec 23.8 MBytes 19.0 > > Mbits/sec receiver > > > > iperf Done. > > Sorry. I meant not running iperf server nor client on AP. A bit more > graphic: > > Notebook --> AP --> PC > > Iperf client on notebook and iperf server on PC. Notebook to AP is > wireless, AP to PC is wired. I see! Howver, this needs routing on the AP, which I have not done yet. What do you expect from this test? I compared the values from the Ethernet test with an Application Note [1] I found at NXP for the i.MX28. Running iperf shows an throughput of >60 MBits/sec. I run the test cases again without Powerline adapter by connecting both devices directly to the Router and even installed iperf (instead of iperf3). Nevertheless, I am stuck with 20 MBits/sec. Note, that the Application Note was done with a legacy Linux Kernel 2.6 whereas I use mainline Linux Kernel 4.7. Maybe something is missing in mainline? For now, I will consider that brcmfmac is not responsible for the low throughput and I will move this issue to the ARM linux mailing list. Many thanks so far for the support! I will keep you in the loop. [1] http://cache.freescale.com/files/32bit/doc/app_note/AN4544.pdf Best regards Jörg Krause ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: TCP data throughput for BCM43362 2016-10-12 19:08 ` Arend van Spriel 2016-10-12 19:30 ` Jörg Krause @ 2016-10-12 20:48 ` Jörg Krause 1 sibling, 0 replies; 23+ messages in thread From: Jörg Krause @ 2016-10-12 20:48 UTC (permalink / raw) To: Arend van Spriel Cc: brcm80211-dev-list, Brett Rudley, Franky Lin, Hante Meuleman, linux-wireless, Franky Lin, Arend van Spriel On Wed, 2016-10-12 at 21:08 +0200, Arend van Spriel wrote: [snip] > > 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. Note, that a user reported "low" throughput on i.MX28 (same processor I use with BCM43362) using Qualcom/Atheros QCA 6124 only seeing 20MB using iperf [1]. [1] https://community.nxp.com/thread/353921 Best regards Jörg Krause ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2016-10-12 22:50 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-08-05 20:46 TCP data throughput for BCM43362 Jörg Krause
[not found] ` <CAF7Mx6o+WuQqtzuApMWQ8YAkLSX7xQ_H06xmO--RxFdwHwzLdQ@mail.gmail.com>
2016-08-05 21:29 ` Jörg Krause
[not found] ` <CA+8PC_f7VQMwBfQmZZ_vUtYtNJKVYzmFmxziAwoG8-iRUeW9Jw@mail.gmail.com>
2016-08-06 8:07 ` Jörg Krause
2016-08-06 14:12 ` Jörg Krause
2016-08-07 11:41 ` Arend van Spriel
2016-08-12 9:25 ` Jörg Krause
2016-08-22 13:37 ` Jörg Krause
2016-08-24 18:35 ` Arend Van Spriel
2016-08-29 21:15 ` Jörg Krause
2016-09-14 13:41 ` Jörg Krause
2016-09-14 18:13 ` Arend Van Spriel
2016-09-19 6:36 ` Jörg Krause
2016-09-21 14:15 ` Arend van Spriel
2016-09-22 8:09 ` Arend Van Spriel
2016-09-22 12:52 ` Jörg Krause
[not found] ` <CAF7Mx6q+B4RoURNF5XxewjF9aVGCXg==XU0aDD6w+354yXZ70Q@mail.gmail.com>
2016-10-11 6:14 ` Jörg Krause
2016-10-12 8:11 ` Arend Van Spriel
2016-10-12 14:27 ` Jörg Krause
2016-10-12 19:08 ` Arend van Spriel
2016-10-12 19:30 ` Jörg Krause
[not found] ` <CAF7Mx6rqfbhDL-MRZ93vzCdSskgqi_bVNn=1SGb_WKV=DZZ+YQ@mail.gmail.com>
2016-10-12 21:19 ` Jörg Krause
[not found] ` <CAF7Mx6pD5VZ57PHy5DSj8yLOLY4vir2JhEdEL8SB3kr91OqFsQ@mail.gmail.com>
2016-10-12 22:50 ` Jörg Krause
2016-10-12 20:48 ` Jörg Krause
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.