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?

[grzegorz]

I'm also waiting fot the answer. If I set CONFIG_BT_BUF_ACL_TX_COUNT=10 then I get warning:

<wrn> bt_hci_core: Num of Controller's ACL packets != ACL bt_conn_tx contexts (3 != 10)

So it seems there is no point in changing CONFIG_BT_BUF_ACL_TX_COUNT?

[variant]

grzegorz For your case, did you set both the app core and net core to CONFIG_BT_BUF_ACL_TX_COUNT=10? It seems that your net core has 3 buffers and your app core has 10.

For the HCI_LE_Read_Buffer_Size command, per the spec:

It seems the warning is that you are configuring the host with 10 buffers to send to the controller, but the controller has only 3, which is inefficient.

[grzegorz]

Thank you variant  I'm sorry I didn't notice it's about nRF5340. I'm using NRF54L15 and there is just one core.

[Amanda Hsieh]

Hi Mike, 

Happy New Year! 

Sorry for the late reply. I got the following answers from the team:

variant said:

a. Can you please just reply yes or no to the question: Is there any benefit if you set the network core CONFIG_BT_BUF_ACL_RX_SIZE to greater than 251 if the app core has CONFIG_BT_BUF_ACL_RX_SIZE=500 (the MTU size)?

No. Making it bigger than 255 on the network core shouldn't bring any benefit.

variant said:

b. Again, this can have a yes or no reply:  Does the SDC nak a received packet if it doesn't have enough CONFIG_BT_CTLR_SDC_RX_PACKET_COUNT buffers for a particular connection to store the packet? If so, we can use a sniffer to know if that is happening.

In such a case, SDC will NAK a received packet only if a device has some data to send. If the device doesn't have any data to send, it will simply close the current connection event (so it will not send an empty packet just to NAK reception) and will receive retransmission of the packet in the next connection event. However, it is an implementation detail, so we don't recommend relying on this behavior.

variant said:

c.  I was hoping to get a suggestion for best throughput such as set the CONFIG_BT_BUF_ACL_TX_COUNT in the app core to be larger than the net core's value.  Or, should the app core and net core values be equal for best throughput? Can you provide such a suggestion?

I can't provide any universal recommendation. My suggestion would be to fine-tune the amount and sizes of buffers depending on application needs and CPU utilization.

-Amanda H.

[variant]

Hi Amanda, 
Happy New Year to you too.

Your above reply is exactly what I was looking for.

This part of the reply was very telling:

Amanda Hsieh said:

No. Making it bigger than 255 on the network core shouldn't bring any benefit.

I assume 255 is the 251 plus 4 bytes for the MIC or the 4 bytes for the l2cap header.

Anyway, I think it would be useful if this fact were documented somewhere, especially as a comment in the Throughput sample network core .conf file. In fact, the Throughput sample sets the default value to 502 instead of 255 for the network core:  CONFIG_BT_BUF_ACL_RX_SIZE=502. 

Similarly, as I pointed out in an earlier reply, it would be nice if the Throughput sample used a more reasonable CONFIG_HEAP_MEM_POOL_SIZE instead of 8192 (see the same file I linked above).  As I said earlier, with multiple connection support, the network core memory use becomes significant, so having reasonable default values would be useful for people to see when they look at the Throughput sample for guidance.