Wi-Fi stack configuration and performance
This guide provides information on the configuration of the Wi-Fi® stack and the nRF Wi-Fi driver’s performance.
Zephyr OS factors
The following sections explain the factors that are applicable when using the Zephyr OS on the nRF5340 SoC.
CPU frequency
The nRF5340 host has two operating frequencies, 64 MHz and 128 MHz, default frequency is 64 MHz. For low power applications, it is recommended to use 64 MHz as the CPU frequency, but the Wi-Fi performance of the nRF70 Series device might be impacted. For high performance applications, it is recommended to use 128 MHz as the CPU frequency.
Networking stack
The nRF Wi-Fi driver uses the Zephyr networking stack for Wi-Fi protocol implementation. You can configure the networking stack to use different networking buffers and queue depths. The nRF Wi-Fi driver can be configured to use different numbers of TX buffers and RX buffers based on the use case. A separate configuration option is provided to configure the number of packets, and the number of buffers used by each packet can also be configured.
The following table explains the configuration options:
Configuration Option |
Values |
Description |
|---|---|---|
|
Number of TX packets. This is the TX queue depth, higher depth saturates the Wi-Fi link but consumes more memory, lower depth reduces memory usage but does not saturate the Wi-Fi link leading to poor performance. |
|
|
Number of RX packets. This is the RX queue depth, higher depth can keep up with the RX traffic but consumes more memory, lower depth reduces memory usage but does not keep up with the RX traffic leading to packet drops. |
|
|
Number of TX buffers. Typically for Wi-Fi, each packet has two buffers, so this has to be twice the number of packets. |
|
|
Number of RX buffers. Typically for Wi-Fi, each packet has one buffer, so this has to be equal to the number of packets. |
nRF Wi-Fi driver performance and memory fine-tuning controls
The nRF Wi-Fi driver provides the following software configurations to fine-tune memory and performance based on the use case:
Configuration Option |
Values |
Description |
Impact |
Purpose |
|---|---|---|---|---|
|
Enable or disable Wi-Fi Protected Access (WPA™) supplicant |
Memory savings |
This specifies the inclusion of the WPA supplicant module. Disabling this flag restricts the nRF Wi-Fi driver’s functionality to STA scan only. |
|
|
Enable or disable Access Point (AP) mode |
Memory savings |
This specifies the inclusion of the AP mode module. Disabling this flag restricts the nRF Wi-Fi driver’s functionality to Station mode (STA) only. |
|
|
Enable or disable Wi-Fi direct mode |
Memory Savings |
This specifies the inclusion of the P2P mode module. Disabling this flag restricts the nRF Wi-Fi driver’s functionality to STA or AP mode only. |
|
|
Maximum number of TX tokens. These are distributed across all WMM® access categories (including a pool for all). |
Performance tuning and Memory savings |
This specifies the maximum number of TX tokens that can be used in the token bucket algorithm. More tokens imply more concurrent transmit opportunities for RPU but can lead to poor aggregation performance if the pipeline is not saturated. But to saturate the pipeline, a greater number of networking stack buffers, or queue depth, is required. |
|
|
Maximum number of frames that are coalesced into a single Wi-Fi frame (for example, MPDU’s in an A-MPDU, or MSDU’s in an A-MSDU). The coalescing greatly improves the throughput for small frames or under high traffic load. |
Performance tuning and Memory savings |
This specifies the maximum number of frames that can be coalesced into a single Wi-Fi frame. More frames imply more coalescing opportunities but can add latency to the TX path as we wait for more frames to arrive. |
|
|
Number of RX buffers |
Memory savings |
This specifies the number of RX buffers that can be used by the nRF Wi-Fi driver. The number of buffers must be enough to keep up with the RX traffic, otherwise packets might be dropped. |
|
|
Maximum TX data size |
Memory savings |
This specifies the maximum size of Wi-Fi protocol frames that can be transmitted. Large frame sizes imply more memory usage but can efficiently utilize the bandwidth. If the application does not need to send large frames, then this can be reduced to save memory. |
|
|
Maximum RX data size |
Memory savings |
This controls the maximum size of the frames that can be received by the Wi-Fi protocol. Large frame sizes imply more memory usage but can efficiently utilize the bandwidth. If the application does not need to receive large frames, then this can be reduced to save memory. |
The configuration options must be used in conjunction with the Zephyr networking stack configuration options to achieve the desired performance and memory usage. These options form a staged pipeline all the way to the nRF70 Series chip, any change in one stage of the pipeline will impact the performance and memory usage of the next stage. For example, solving bottleneck in one stage of the pipeline might lead to a bottleneck in the next stage.
nRF70 Series packet memory
The nRF70 Series device chipset has a special memory called the packet memory to store the Wi-Fi protocol frames for both TX and RX. The various configuration options that control the size of the packet memory are listed below:
The packet memory is divided into two parts, one for TX and one for RX. The size of the TX packet memory is calculated as follows:
(CONFIG_NRF700X_TX_MAX_DATA_SIZE + 52 ) * CONFIG_NRF700X_MAX_TX_TOKENS * CONFIG_NRF700X_MAX_TX_AGGREGATION
The size of the RX packet memory is calculated as follows:
CONFIG_NRF700X_RX_MAX_DATA_SIZE * CONFIG_NRF700X_RX_NUM_BUFS
The total packet memory size is calculated as follows:
(CONFIG_NRF700X_TX_MAX_DATA_SIZE + 52 ) * CONFIG_NRF700X_MAX_TX_TOKENS * CONFIG_NRF700X_MAX_TX_AGGREGATION +
CONFIG_NRF700X_RX_MAX_DATA_SIZE * CONFIG_NRF700X_RX_NUM_BUFS
There is a build time check to ensure that the total packet memory size does not exceed the available packet memory size in the nRF70 Series chip.
Note
The 52 bytes in the above equations are the overhead bytes required by the nRF70 Series chip to store the headers and footers of the Wi-Fi protocol frames.
Usage profiles
The nRF Wi-Fi driver can be used in the following profiles (not an exhaustive list):
Features |
Profile |
Configuration Options |
Use cases |
Throughputs |
|---|---|---|---|---|
STA scan only |
Scan only |
|
Location services |
|
STA mode |
IoT devices |
|
IoT devices |
|
STA mode |
Memory optimized STA mode |
|
Sensors with low data requirements |
|
STA mode |
High performance STA mode |
|
High data rate IoT devices |
|
STA mode |
TX prioritized STA mode |
|
Sensors with high data rate |
|
STA mode |
RX prioritized STA mode |
|
Display devices streaming data |
|
Note
The measured throughputs, as shown in the table above, are based on tests conducted using the nRF7002 DK. The results represent the best throughput, averaged over three iterations, and were obtained with a good RSSI signal in a clean environment.
The above configuration values can be passed using standard ways such as CMake arguments to west build (Zephyr One Time Arguments or Zephyr Permanent Arguments), or by adding them in an overlay file and passing to west build as CMake argument EXTRA_CONF_FILE.
See Zephyr Application Configuration for more details.