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

[Edvin]

Hello,

Samruddhi asked if I could have a look at your ticket. 

Can you please try to capture a sniffer trace of the connection (both with v2.6.0 and with v2.9.2) using the nRF Sniffer for Bluetooth LE?

Also, which configuration should I use to reproduce what you are seeing? just the default prj.conf? I don't see any logs.

What MTU and Data length do you actually see in your connection? To see how it is negotiated, please see:
https://academy.nordicsemi.com/courses/bluetooth-low-energy-fundamentals/lessons/lesson-3-bluetooth-le-connections/topic/blefund-lesson-3-exercise-2/?version=v2.9.0-v2.7.0

Best regards,

Edvin

[chiba]

Hi,

I am sending you the project, including the build directory.
You should be able to reproduce the issue by flashing this to the DK board.

I am also sending you the capture data from the NRF Sniffer

8154.lock_5340dk_ncs260.zip

2620.lock_5340dk_ncs292.zip

7360.central_52840dk.zip

ncs260.pcapng

ncs292.pcapng

[Edvin]

Hello,

Is the ncs260 device and ncs292 device running on the same exact HW, and under similar conditions? The reason I ask is that I can't seem to see any difference in behavior, but there seems to be a bit more packet loss in the latter trace.

That said, it seems like both traces show a chunk of 158 byte long messages. Sometimes 6 packets, sometimes 5 and sometimes 4. Not an awful lot of data. 

Do you mean that they should always be the same? E.g. 5 or 6 packets? 

Where in your application (both in 2.6.0 and 2.9.2) do you transmit this data? 

Regardless of packet loss, the data should go through, as long as it is queued with a return value of Success (0). 

Can you confirm that this is the case? That you check the return value when you queue up the data for TX?

Best regards,

Edvin

[chiba]

Hi,

Both ncs2.6.0 and ncs2.9.2 are being operated on the same DK board. I have sent the project files, so could you please perform a packet capture on the Nordic side as well?

Here is the background regarding this issue:

1. We discovered that the throughput differs between ncs2.6.0 and ncs2.9.2 in a certain product, with ncs2.9.2 being slower. After capturing the BLE packets, we confirmed that the number of "More Data" packets differs between ncs2.6.0 and ncs2.9.2. This was the starting point of the DevZone topic.

2. Samruddhi Jadhav requested that we provide the project.

3. I have created and provided a test project for the DK board so that the issue can be reproduced on your end.