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

[Elias]

In my application, we regularly transmit a stream of notifications from a Peripheral Server to a Central Client. The general strategy for this is to enqueue a packet, and then wait for a BLE_GATTS_EVT_HVN_TX_COMPLETE to enqueue another one. I have noticed that if I synchronously enqueue three packets at the start of the stream before I wait for transmissions, then overall throughput is much faster (by about a factor of three) than if I only enqueue two at the start of the stream. Why is this? 

I have kept hvn_tx_queue_size at 1, and my notifications and MTU are sized such that hvn_tx_complete.count is always 1. Why am I allowed to enqueue three packets at all?

I am using SoftDevice s132 v5.1.0.

[Einar Thorsrud]

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.

1. Why am I allowed to enqueue three packets at all?

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.