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

Hello,

Are you sure you are performing GATTC Characteristic or Descriptor Value Reliable Write (aka write requests) and not GATTC Characteristic Value Write Without Response (aka write commands). Write requests will lead to a considerably lower throughput because you can't issue multiple write requests in parallel (the stack needs to wait for the write response to come back before issuing a new request).  This effectively limits you to write per connection event.  

1. As mentioned above, it's not possible to send multiple write requests in one connection event.

2. An easier way to deal with this, assuming you use write commands, is to increase the write_cmd_tx_queue_size (see this post). This defines the number of packets you can add to the Softdevice's write output buffer.

Best regards,

Vidar

[xiaolongba]

Hello Bro,

Vidar Berg said:

Are you sure you are performing GATTC Characteristic or Descriptor Value Reliable Write (aka write requests) and not GATTC Characteristic Value Write Without Response (aka write commands). Write requests will lead to a considerably lower throughput because you can't issue multiple write requests in parallel (the stack needs to wait for the write response to come back before issuing a new request).  This effectively limits you to write per connection event.  

I used the write commands, sorry for the misunderstanding.

Vidar Berg said:

1. As mentioned above, it's not possible to send multiple write requests in one connection event.

I can get your point, 

xiaolongba said:

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?

but I used the write cmd. so for this situation, my understanding above if it is correct？

Vidar Berg said:

2. An easier way to deal with this, assuming you use write commands, is to increase the write_cmd_tx_queue_size (see this post). This defines the number of packets you can add to the Softdevice's write output buffer.

I have checked this link, also I understood that it is used for high throughput when increasing the queue size, but what I was confused about is :

1. for queue size, is it only for write cmds cache, without payload? but as you know, each write cmd will carry some payload, such as 200 bytes. which parameters are used for these payload caches? I don't know if I explained clearly, in other words, there is one write cmd with 200bytes payload, and queue size can cover the cmd and payload together?

[xiaolongba]

Hello Victor Bro,

Based on the issue above, I would like to ask you another question about it. as you know, I tried to optimize the max throughput based on the solution above but found that the following warning has been triggered:

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

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

also I understood how to fix this warning, that is to increase the NRF_SDH_BLE_GAP_EVENT_LENGTH value from 4 to 5,

However, I would like to know where are 16 bytes coming from? how to calculate it. could you share the formula for it? I need your help, Bro.

thanks in advance.

[Vidar Berg]

xiaolongba said:

for queue size, is it only for write cmds cache, without payload? but as you know, each write cmd will carry some payload, such as 200 bytes. which parameters are used for these payload caches? I don't know if I explained clearly, in other words, there is one write cmd with 200bytes payload, and queue size can cover the cmd and payload together

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.

xiaolongba said:

how to calculate it. could you share the formula for it?

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