ble througput issues with nimble/ble_conn_mgr (IDFGH-17832)

[boborjan2]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

We have a setup where Linux writes a GATT characteristic on a esp32 ble peripheral.
When using the ble_throughput_server example that uses bluedroid, we can reach ~83kbyte/s throughput that is close to the theoretical max. (MTU 247, conn interval 7.5ms or 15ms)
However when using nimble/ble_conn_mgr (which we intend), we cannot go higher than 60kbyte/s. We set MTU to the same 247, update conn_params (connection interval to 7.5ms (or 15ms), ce_length to 7.5ms etc). What else affects nimble behavior?

esp32_ble_nimble.pcapng.gz
(in this log, chunks of 8192 are sent in series. Sending one chunk takes ~140ms. There are 5ms gaps between packets that are not there with bluedroid)

[boborjan2]

I just see that there is a throughput example for nimble as well, where it is stated that the expected max is ~500kbit/s that we could already reach. Why is nimble that slower?
Another angle: I see that there are stubs in ble_conn_mgr for bluedroid implementation. When can we expect the bluedroid port to be available? Are there already plans for this?

Cheers, Viktor

[rahult-github]

Hi @boborjan2 ,

Indeed the throughput for nimble example is less , but that is due to incorrect connection parameters. The demo example though shows the correct usage of APIs to achieve data transfer , but various parameters aren't fine tuned to give the highest throughput as the example has multiple operations. We are working on it and will share a working patch quickly

[Mayank-npc]

Hi @boborjan2 ,

The issue is due to non-optimized parameters that fail to use the complete bandwidth . Existing application used same set of parameters for every operation which leads to this issue. Please find a fix that addresses this behaviour.

For reference, we see 750 kbps (1M ) and around 1.34 Mbps ( 2M ) in our local testing. While we continue to stress test and make this robust, you can try the attached patch at your end in meantime. The patch is to be applied in $IDF_PATH.

Also this patch is prepared against the master branch if you face any issue while applying this patch do share me your release branch name and commit ID.

throughput.patch