BLE throughput differs between NCS v2.6.0 and v2.9.2.

[chiba]

Hi,

BLE throughput differs between NCS v2.6.0 and v2.9.2.
v2.9.2 appears to have fewer MoreData packets.
(Both have CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT set to 7500)

In v2.9.2, I confirmed that setting `CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT=15000` changes the number of more data packets.
Is there a difference in how `CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT` is handled between v2.6.0 and v2.9.2?

- Using the nrf5340
- Configured for multi-protocol communication with Matter (At the time of this test, commissioning had not been performed, and no Matter communication was taking place)

[Samruddhi Jadhav]

Hello,

Can you please upload your whole application in v2.9.2?

Best Regards,

Samruddhi

[chiba]

HI, I've created a project so you can reproduce it on a DK board.

Overview

Packets are periodically transmitted from the Central to the Peripheral.
Once both devices are powered on, they connect automatically and transmit packets at 1-second intervals.

Project Details

• central_52840dk
  - Description: Central-side project for the nRF52840 DK.
  - Base: ncs292/zephyr/samples/bluetooth/central
• lock_5340dk_ncs260
  - Description: Peripheral-side project for the nRF5340 DK (NCS 2.6.0).
  - Base: ncs260/nrf/samples/matter/lock
• lock_5340dk_ncs292
  - Description: Peripheral-side project for the nRF5340 DK (NCS 2.9.2).
  - Base: ncs292/nrf/samples/matter/lock

8055.lock_5340dk_ncs292.zip

7624.lock_5340dk_ncs260.zip

1856.central_52840dk.zip

[chiba]

Hi,

I believe the underlying throughput issue stems from differences in MD packets.
It appears that the NCS292 can transmit fewer MD packets per CI.
The sample project I provided is intended solely for verifying these differences in MD packets.
I am not concerned with throughput or data loss in this project.

> From your ...292.pcapng trace I saw that there wass a lot of packet loss, but the traces themselves can't tell why the central didn't try to send more packets.

This is exactly what I want to check.

[Edvin]

I realized something.

While yes, there were retransmissions, I thought it was because the radio was reserved for Thread, and perhaps the default value did change between 2.6.2 and 2.9.2.

Try adding this to your lock_5340_292 application:

sysbuild\ipc_radio\boards\nrf5340dk_nrf5340_cpunet.conf:

CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT_OVERRIDE=y
CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT=20000

What this does is that it tells the device that it can spend more time each connection interval handling one BLE connection. In this case 20ms. It does not mean it will spend 20ms in cases where there is no more data being sent. It does however mean that when there is a lot of data on BLE, it will spend less data on Thread, leading to poorer Matter performance. Retransmissions will handle this, so you shouln't ultimately loose any packets. It is simply a tradeoff whether you want to prioritize radio time on BLE or Matter.

Using this, I see that all 8 packets are sent within one connection interval, as you can see in the attached trace, but feel free to check this yourself:

new_trace_2_292.pcapng

FYI: I used a slightly modified version of your sample while working on this, so that it uses a static address on every boot, to easier find it on the BLE sniffer:

lock_5340dk_ncs292_mod.zip

Look for a device advertising using the address: C0:DE:DE:AD:DE:AF (the advertising name is still the same.

Best regards,

Edvin

[chiba]

HI,

I understand that the state changes with CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT.

However, the default value is set to 7500 for both NCS260 and NCS292.

- NCS292:  build\ipc_radio\zephyr\include\generated\zephyr\autoconf.h

- NCS260: build\multiprotocol_rpmsg\zephyr\include\generated\autoconf.h

Why do they behave differently?

[Edvin]

I do see that there have been some changes to the SoftDevice controller regarding the reset state of the softdevice controller between these versions, which probably explains the difference in behavior. 

In v2.9.2 changelog, there is an explicit change:

Extended Connection Events are not re-enabled on HCI Reset; previous state is preserved.

See v2.9.2/nrfxlib/softdevice_controller/CHANGELOG.rst

In v2.6.2 API docs, conn event extend says that after HCI Reset, Extended Connection Events are enabled by default.

Please see these:

https://github.com/nrfconnect/sdk-nrfxlib/blame/v2.9.2/softdevice_controller/CHANGELOG.rst#L100

https://github.com/nrfconnect/sdk-nrfxlib/blob/v2.6.2/softdevice_controller/include/sdc_hci_vs.h#L980

That should explain the difference in behavior. Now that you know how to configure it in v2.9.2, you can tune it to work the way that you want it to work in your application.

Best regards,

Edvin

[chiba]

Hi,

Thanks, I understand now.

To make it behave the same as NCS262, should I just add the following setting?

CONFIG_BT_CTLR_SDC_CONN_EVENT_EXTEND_DEFAULT=y

[Edvin]

Yes, as well as:

CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT=20000

[µs] Adjust this one to as long as the maximum amount of time you want the device to spend on the BLE connection. Remember that it will not spend this time unless the other device has data to send. But if the connected device has a lot of data, it may spend up to this amount of µs for BLE on every connection interval (meaning this amount of time will not be spent on Matter/Thread).

Best regards,

Edvin

[chiba]

Hi,

I understand the description of CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT.

I would like to know how to configure it so that it behaves the same as lock_5340dk_ncs260.

For lock_5340dk_ncs260 and lock_5340dk_ncs292, CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT is set to 7500.

To make lock_5340dk_ncs292 behave the same as lock_5340dk_ncs260, should it be changed to 2000?

[Edvin]

yes.

BR,
Edvin