Choice of controller configurations in BLE Throughput sample

[variant]

I am referring to the ncs\v3.1.0\nrf\samples\bluetooth\throughput\sysbuild\ipc_radio\prj.conf for the nRF5340 and extrapolating that to a central application with multiple peripheral connections. In that case, RAM use on the network core becomes a concern. 

1. Why does the sample have such a large heap size (CONFIG_HEAP_MEM_POOL_SIZE=8192)? I am not aware of any k_malloc() use in the Throughput sample and ipc_radio.

* Yes, we can use a "minimal.conf", but why put such a large default of 8192 in the Throughput prj.conf?

2. Why doesn't the sample suggest adjusting other configurations, notably the CONFIG_BT_CTLR_SDC_TX_PACKET_COUNT, CONFIG_BT_CTLR_SDC_RX_PACKET_COUNT, and CONFIG_BT_BUF_ACL_TX_COUNT? Couldn't these influence throughput?

* See my case 296354, where increasing CONFIG_BT_CTLR_SDC_TX_PACKET_COUNT influenced keeping the More Data (MD) bit set.

3. In that case 296354, there was a statement:
"There is no need to maintain any ratio or relationship between CONFIG_BT_CTLR_SDC_TX_PACKET_COUNT and CONFIG_BT_BUF_ACL_TX_COUNT. Also, the latter is only used by the Zephyr LL. (Generally, the difference between BT_BUF_ACL_TX_COUNT and BT_CTLR_SDC_TX_PACKET_COUNT is that the latter is per connection while the former is shared. This does not matter for a single connection, though.)"

That was for an old NCS, 2.0. I believe CONFIG_BT_BUF_ACL_TX_COUNT is indeed used by the SDC in newer NCS versions, such as NCS 2.6 and beyond. Is that correct?

[brjohnson]

Hello Amanda, I wanted to jump in here and ask for a little clarification on your statement about the Controller returning CONFIG_BT_BUF_ACL_TX_COUNT as the response to the HCI LE Read Buffer Size command.

I am in the process of updating our nRF5340 application to NCS 3.2 and have been seeing the "<wrn> bt_hci_core: Num of Controller's ACL packets != ACL bt_conn_tx contexts (3 != 10)" log that is mentioned elsewhere in this thread. I have verified that both the application and ipc_radio configuration have CONFIG_BT_BUF_ACL_TX_COUNT set to 10, and yet I am still seeing this exact warning. I suspect that 
the controller is actually using CONFIG_BT_CTLR_SDC_TX_PACKET_COUNT as when I set that to 10 in the ipc_radio config, the warning goes away. This obviously does not make sense as ACL_TX_COUNT refers to number of buffers shared among connections, whereas SDC_TX_PACKET_COUNT is specified as per connection.

This can be easily recreated with the throughput sample building for nrf5340dk/nrf5340/cpuapp. If you add the following to prj.conf in a clone of the throughput sample:

CONFIG_LOG=y
CONFIG_BT_LOG_LEVEL_WRN=y

You will see the exact warning log mentioned above.

You can then add 

CONFIG_BT_CTLR_SDC_TX_PACKET_COUNT=10

to sysbuild/ipc_radio/prj.conf and rerun the sample and observe that the warning has gone away. Would you be able to comment on this behavior?

[variant]

Hi brjohnson 
You are correct that the controller returns CONFIG_BT_CTLR_SDC_TX_PACKET_COUNT as the response to the host's HCI LE Read Buffer Size command. I can see that myself via logging.

But why do you say 

brjohnson said:

This obviously does not make sense as ACL_TX_COUNT refers to number of buffers shared among connections, whereas SDC_TX_PACKET_COUNT is specified as per connection.

By using the CONFIG_BT_CTLR_SDC_TX_PACKET_COUNT instead of CONFIG_BT_BUF_ACL_TX_COUNT in the reply, to me, the controller is telling the host it can accommodate CONFIG_BT_CTLR_SDC_TX_PACKET_COUNT no matter if there is one connection active or more than one connection active.