The true throughput

[Anonymous]

Hello All,

The throughput of these BRCM chips is a big question mark. I have been using one module with STM32 and SPI (Inventek) and I am able to get sustained 5-6Mbps. However this is far from the true capability of this technology and there is really no clear benchmark out there. I wish there was one.

BCM43362 Modules Throughput

The thread above has some information. This information is inline with my expectatios however some claims are questionable. Our admin claims 30-40Mbps using SDIO. Has this ever been demonstrated? For example using Linux iMx6 and SDIO modules? I very much like to know this.

In addition there is a link with some decent data SN8200 maximum TCP data throughput ?

This thread concludes BCM4390 is the best solution for performance. The thread says M3/M4+Wiced with SPI limited bw.

ACk.me guys also make claims about 14Mbit via SPI and 5Mbit via Uart but no measurement results are shared.

So, in summary my questions are:

- If we use Linux and SDIO what can be achieved with BRCM Wiced ics?

- Which IC will provide the best performance?

[Anonymous · Accepted solution]

"Has this ever been demonstrated? For example using Linux iMx6 and SDIO modules?"

I response to above question. Below you can see that on a 20Mhz channel the TCP tput is ~40Mbps. This is running in open air, and  could potentially get better through running it in a shield room.

I am not sure why you chose SPI as your interface. Broadcom recommends using SDIO.

> Please find logs below using a 4343w with iMX6 Ultralite.

================== TCP througput with 4343W ==============================================

root@imx6ulevk:~# iperf -s -w 4M -i 1

------------------------------------------------------------

Server listening on TCP port 5001

TCP window size: 8.00 MByte (WARNING: requested 4.00 MByte)

------------------------------------------------------------

[  4] local 192.168.1.1 port 5001 connected with 192.168.1.10 port 52908

[ ID] Interval       Transfer     Bandwidth

[  4]  0.0- 1.0 sec  4.88 MBytes  41.0 Mbits/sec

[  4]  1.0- 2.0 sec  4.50 MBytes  37.7 Mbits/sec

[  4]  2.0- 3.0 sec  2.45 MBytes  20.6 Mbits/sec

[  4]  3.0- 4.0 sec  5.71 MBytes  47.9 Mbits/sec

[  4]  4.0- 5.0 sec  4.61 MBytes  38.7 Mbits/sec

[  4]  5.0- 6.0 sec  5.37 MBytes  45.1 Mbits/sec

[  4]  6.0- 7.0 sec  5.45 MBytes  45.8 Mbits/sec

[  4]  7.0- 8.0 sec  4.78 MBytes  40.1 Mbits/sec

[  4]  8.0- 9.0 sec  5.54 MBytes  46.5 Mbits/sec

[  4]  9.0-10.0 sec  5.46 MBytes  45.8 Mbits/sec

[  4]  0.0-10.7 sec  51.8 MBytes  40.7 Mbits/sec

^Croot@imx6ulevk:~# wl ver

1.107 RC5.0

wl0: Dec 29 2015 16:06:30 version 7.45.41.24 (r608913) FWID 01-a9b9f607

root@imx6ulevk:~# wl chanspec

1 (0x1001)

root@imx6ulevk:~#

root@imx6ulevk:~#

root@imx6ulevk:~#

root@imx6ulevk:~# wl revinfo

vendorid 0x14e4

deviceid 0x43e2

radiorev 0x3da000

chipnum 0xa9a6

chiprev 0x1

chippackage 0x3

corerev 0x27

boardid 0x726

boardvendor 0x14e4

boardrev P101

driverrev 0x72d2918

ucoderev 0x413080c

bus 0x0

phytype 0xc

phyrev 0x0

anarev 0x0

nvramrev 0

root@imx6ulevk:~# wl -i wl0.1 status

SSID: "vs-imx"

Mode: Managed   RSSI: 0 dBm     SNR: 0 dB       noise: 0 dBm    Channel: 1

BSSID: FC:DB:B3:84:98:31        Capability: ESS ShortPre ShortSlot

Supported Rates: [ 1(b) 2(b) 5.5(b) 6 9 11(b) 12 18 24 36 48 54 ]

HT Capable:

        Chanspec: 2.4GHz channel 1 20MHz (0x1001)

        Primary channel: 1

        HT Capabilities:

        Supported MCS : [ 0 1 2 3 4 5 6 7 87 88 ]

[Anonymous]

Hi guys,

For what it's worth, I'm also trying to assess/bump the performance of one of these SDIO modules, and by putting it in a PC I get close to the theoretical limit throughput, while putting it on an SBC with tunable CPU performance (eg. Raspberry Pi, also not using WICED drivers) I can see that the throughput quickly gets limited by not by radio stuff, but by the host CPU speed (eg. 100 MHz -> 10 Mb/s, 200 MHz -> 20 Mb/s); of course that's running Linux so there are a lot of OS-related factors, which you might not have if you're "talking dirty" directly with the chip.

At first sight it seems to me that (at low CPU speeds) the Linux driver spends a considerable amount of time actively waiting for completion of transmissions, instead of doing “fire and forget” and checking completion on an as-needed basis.