【GATT Queue】How to Configure the stack FIFO

[xiaolongba]

Hello Nordic experts,

Recently, I would like to implement high throughput with multi links. to optimize the system, I have the following doubts:

First of all, let me introduce the background:

• 1. 52840 for central, while 4~8 52832 for peripheral
• SDK: nRF SDK 17.1.0
• the total solution can work as expected, but I need to optimize for the best performance.

so my questions are as below:

1. . I used the gatt queue lib for this case, the default queue length is 4, that means SD can hold 4 write requests. I assumed that the SD received 4 write requests before the next connection event is coming, so the SD can transmit these 4 write requests one by one when the connection event has come (CE length is enough).  am I correct?
2. also, as you know, each write request will carry the payload, such as 200bytes. it is the same as item1, the SD received 4 write requests before the next connection event is coming, which parameters can be used for these 4*200 byes cache? if the data pool is for this purpose? I mean, these 4 wire requests will carry 4*200 bytes payload, there is one place for wire quest cache, but which parameters for payload cache? data pool? or other parameters? 

regarding the 2 questions above, could you give me a hand?

thanks in advance.

[Vidar Berg]

Hi,

The time it takes to transmit and and receive the packet does not map 1:1 with the required event length because there's additional overhead such as post processing that need to be accounted for as well. We have not documented a formula which covers all scenarios (is not as easy as it may sound). Instead we have made the Softdevice notify the application when the event length is too short for a given packet length as you have seen.

xiaolongba said:

got it, I still would like to know what is the difference between GATT queue and write_cmd_tx_queue_size ? could you help me clarify?

It makes a bit more sense to use the BLE GATT Queue module when you're doing GATT procedures that can't run in parallel. For instance, write requests where you have to wait for the write response before the Softdevice allows you to queue up the next.

sd_ble_gattc_write() already lets you add 'write_cmd_tx_queue_size' number of write command packets to the Softdevice's output buffer, so you typically don't need to keep an additional buffer in the app, which basically is what GATT Queue provides.

If you want to use the queue module you need to make sure NRF_BLE_GQ_GATTC_WRITE_MAX_DATA_LEN is set the max. payload length for your write commands. NRF_BLE_GQ_DATAPOOL_ELEMENT_COUNT will determine the max. number of packets you can queue up.

[xiaolongba]

Hi Vidar Bro,

most of them are clear, but the following doubts is still exist:

Vidar Berg said:

NRF_BLE_GQ_GATTC_WRITE_MAX_DATA_LEN is set the max. payload length for your write commands

Does it mean that the payload length of all packets, or one packet?

also what is the relationship between NRF_BLE_GQ_DATAPOOL_ELEMENT_COUNT and NRF_BLE_GQ_DATAPOOL_ELEMENT_SIZE? could you give me an example? such as NRF_BLE_GQ_DATAPOOL_ELEMENT_COUNT=8,NRF_BLE_GQ_DATAPOOL_ELEMENT_SIZE=20. what does it mean? it means that the total payload length is 8*20 =160 bytes?

thanks in advance.

[Vidar Berg]

Hi,

It sets the max. payload length for all packets. But what is the motivation for using the nrf queue module? I forgot to mention earlier that there is a bug in the nrf queue module with the way it handles write commands, please see this thread details: https://devzone.nordicsemi.com/f/nordic-q-a/60557/bug-improvement-in-handling-nrf_error_resources-response-in-gatt-queue-nrf_ble_gq_req_gatts_hvx-processing

[xiaolongba]

Hello vidar Bro,

sorry for the late response as I was on annual leave several days ago

Vidar Berg said:

It sets the max. payload length for all packets.

Got it. so my understanding above is correct?

Vidar Berg said:

But what is the motivation for using the nrf queue module?

no, I just want to know what is the difference between nrf queue module and write_cmd_tx_queue_size