【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.

[xiaolongba]

Vidar Berg said:

My suggestion was to increase the output buffer in the Softdevice rather than increasing the GATT queue module. The write_cmd_tx_queue_size specifies the number of packets (the Softdevice accounts for the max. packet here) you can place in the Softdevice queue.

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?

Vidar Berg said:

Please take a look at the "Suggested intervals and windows" section of the Softdevice specification.

Actually, I looked into this section. but I still can not get the correct value. to explain more clear, let me give you an example, as below:

in my case, the NRF_SDH_BLE_GAP_DATA_LENGTH is 251bytes, while NRF_SDH_BLE_GAP_EVENT_LENGTH is 4.

based on this configuration, the softdevice told me the following error info:

The requested TX/RX packet length is too long by 16 octets

also, I checked Bluetooth spec, the LL data is (251+14)*8 = 2120 us if NRF_SDH_BLE_GAP_DATA_LENGTH is 251 octets and the 1M PHY, so the CE_Length_measured is (2120 + 2120+2*T_IFS) = 4540us, while the NRF_SDH_BLE_GAP_EVENT_LENGTH is 4, so the CE_LENGTH is 4*1.25ms = 5ms, it should cover 4540us, but the sd still reported me the error info, that is 

The requested TX/RX packet length is too long by 16 octets

so I want to know how to get these 16 octets based on the configuration I mentioned above. could you give me a hand, It took me lots of time recently, so your great support is very useful for me.

thanks again, bro.

[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