We use iperf to get wifi throughput or benchmark the network stack on a WICED board. But, that does not guarantee that your WICED board is performing at its best. Is it?
I have the following questions on the iperf throughput data you have got on a WICED board:
- How do you know if the throughput that you get using the iperf is the best for the WICED board you have?
- Are you using appropriate iperf options to test network throughput?
- If not, is there any parameters in WICED which you can tune to achieve the best throughput?
How to increase Wifi Throughput on WICED:
There few parameters that you can tune to achieve the best wifi network throughput that your WICED device can get. Most of the parameters are with respect to the network buffer pool or the network packet pool tuning, TCP window size, etc.
You can find the best of these parameters on the WICED console application. WICED SDK developers typically use the console app to benchmark the wifi network throughput using iperf.
What are the default Network parameters on WICED:
Let’s examine the current set of values from the console app for the 4343x WICED devices which include: 4343W, 43438, 43364:
For other WICED board, find the relevant code in the console.mk file.
These are not the exact lines of code on the console.mk file. There are many conditional statements in between.
I have extracted only the network parameter relevant code to show you what are the parameters look like.
If you want the actual code, then the code for 4343x WICED device starts from line# 160 on console.mk file.
ifeq ($(WICED_DISABLE_COMMON_PKT_POOL),1) GLOBAL_DEFINES += TX_PACKET_POOL_SIZE=14 \ RX_PACKET_POOL_SIZE=12 \ WICED_TCP_TX_DEPTH_QUEUE=10 \ WICED_TCP_WINDOW_SIZE=131072 else WICED_PACKET_POOL_SIZE_128 := 10 WICED_COM_PACKET_POOL_SIZE := 22 GLOBAL_DEFINES += WICED_USE_COMMON_PKT_POOL \ PACKET_POOL_SIZE_128=$(WICED_PACKET_POOL_SIZE_128) \ COM_PACKET_POOL_SIZE=$(WICED_COM_PACKET_POOL_SIZE) \ WICED_TCP_TX_DEPTH_QUEUE=20 \ WICED_UDP_QUEUE_MAX=8 \ WICED_TCP_WINDOW_SIZE=131072
From the above lines of code, you can see that if the common packet pool is disabled (WICED_DISABLE_COMMON_PKT_POOL=1) then TX pool size will be 14, RX pool size will be 12.
In addition, the WICED_TCP_WINDOW_SIZE defines the max TCP window size for the network stack.
If the TX_PACKET_POOL_SIZE and RX_PACKET_POOL_SIZE values are not defined in a makefile of a WICED application, then the values will be set to 7 to each, which comes from wiced_network.c file.
#ifndef TX_PACKET_POOL_SIZE #define TX_PACKET_POOL_SIZE (7) #endif #ifndef RX_PACKET_POOL_SIZE #define RX_PACKET_POOL_SIZE (7) #endif
What is the difference between Individual TX, RX packet pool and a Common packet pool:
Let’s take the example of the above parameters where TX pool is set to 14 and RX pool is set to 12.
In total, you are occupying a pool of 26 packets.
When there is TX traffic (data being transferred from WICED) ONLY the TX pool is used and the RX pool memory is idle.
And the same goes for RX memory pool when running RX traffic.
Approximately 50% of the memory stays UNUSED when running uni-directional traffic.
On the other side, a common packet pool has 22 numbers of packets in the pool which can be FULLY used by either of the network traffic direction.
Theoretically, the common packet pool will give you better throughput over individual TX and RX pools.
I have seen throughput improvement using the Common packet pool on CYW954907 WICED board.
I will write a separate post on this in a later time.
How to change the TX and RX packet pool or TCP Window size parameters on WICED:
TX and RX packet pools are nothing but some buffers which have a max size of WICED_PAYLOAD_MTU on WICED platforms which is 1500 bytes.
So, when you are defining TX packet pool to 14, at an instance you can hold only 14 number of packets. The same goes to RX pool too.
TX packet pool is used for TX traffic and RX packet pool is used for RX traffic. (TX and RX are considered from WICED device’s point of view.)
You can increase these TX and RX pool size or increase the common packet pool size to increase the wifi network throughput.
But there is a catch here. There is a limit to how much size of the pool you can increase to.
As per the code from WICED SDK, these pool(s) are designed to occupy bss memory segment of the program, which resides in RAM.
So, when you increase the packet pool size, you will see an increase in Packet Buffers size and the overall Static RAM usage of the WICED application you are compiling.
You can see the static RAM info when you compile an application on WICED.
Below is the text I have extracted from the BCM943438WCD1 WICED console app build output.
|----------------------------------|---------|---------| | | | Static | | Module | Flash | RAM | |----------------------------------+---------+---------| |Packet Buffers | 0 | 43620 | |----------------------------------+---------+---------| |TOTAL (bytes) | 415828 | 115988 | |----------------------------------|---------|---------|
Make sure the Static RAM size must not increase the total RAM size available on your WICED device.
In fact, the WICED build system will give you an error of RAM overflow.
If you find any difficulty understanding this guide, just login, and reply on this topic. I will try to help you out as much as I can.