RE: Why do I need to enqueue three notifications to achieve optimal throughput?

Einar Thorsrud — Thu, 17 Nov 2022 12:44:12 GMT

Hi,

In bluetooth you can send an arbitrary number of notifications in the same connection event, as long as there is enough remaining time, and the GATT server has more data to send. A key here though is that the serve must already have buffered the next packet so that it can set the more data flag in the current packet, indicating that there is more data to send. So you must have queued at least on extra packet. If not, the connection event will end after the current packet.

This leads to a few important points:

You need to queue data a decent time in advance. If you queue only 2, you need to be sure to queue a new backed before the stack starts processing the second packet, and this can be tight.
The throughput you loose by not queuing enough packets depends on the length of the connection event, as you will effectively loose the rest of the event. If the connection event (and connection interval) was very long, you could see an even greater reduction in throughput than what you have seen.

[quote user=""]1. Why am I allowed to enqueue three packets at all?[/quote]

This is related to the buffer available in the SoftDevice. A long time ago the SoftDevice had a bandwidth configuration, which effectively adjusted the number of buffers (and thus RAM usage) in the SoftDevice. This has changed and with recent SoftDevices the memory usage and buffers are selected based on the event length configuration.