About the multiple ACKs in ATT MTU Throughput Example

[EthanJia]

Hi there

I am testing the ATT MTU throughput test provided by nRF5 SDK and I found the throughput could not reach the theoretical maximum 1.4Mbps.

Hence, I used the nRF Sniffer to analyze, and what I found was that after a certain stage there would be multiple ACKs after an ATT MTU data package.

The thing is that when there was only one ACK, the throughput was about 1.37Mbps ≈ 1.4Mbps. However, when there were multiple ACKs, the throughput was only about 0.6Mbps.

Right now, I suppose that these redundant ACKs were causing a reduction in the throughput, and they were happening almost every time. What could be the cause?

The screenshot of Wireshark is pasted below, and the connection parameters were shown in the following:

#define DATA_LENGTH_DEFAULT             27                                              /**< The stack default data length. */
#define DATA_LENGTH_MAX                 251                                             /**< The stack maximum data length. */

#define CONN_INTERVAL_DEFAULT           (uint16_t)(MSEC_TO_UNITS(400, UNIT_1_25_MS))    /**< Default connection interval used at connection establishment by central side. */

#define CONN_INTERVAL_MIN               (uint16_t)(MSEC_TO_UNITS(7.5, UNIT_1_25_MS))    /**< Minimum acceptable connection interval, in units of 1.25 ms. */
#define CONN_INTERVAL_MAX               (uint16_t)(MSEC_TO_UNITS(500, UNIT_1_25_MS))    /**< Maximum acceptable connection interval, in units of 1.25 ms. */
#define CONN_SUP_TIMEOUT                (uint16_t)(MSEC_TO_UNITS(4000,  UNIT_10_MS))    /**< Connection supervisory timeout (4 seconds). */
#define SLAVE_LATENCY                   0                                               /**< Slave latency. */

Here is how I calculate the max throughput and also other throughput:

Really appreciate it if this could be helped.

Best regards

Ethan

[dejans]

Hi,

Are you using DKs or custom boards?
Could you please provide more information about your setup?

Best regards,
Dejan

[EthanJia]

And the distance between two nRF52 DK boards (master and slave) is about 20cm.

Meanwhile, I am using a nRF52 DK as the sniffer.

The setup is like the following picture:

[dejans]

Hi,

Based on the log, there might not be retransmissions, but missing packets from the master. This could indicate some problem with the sniffer. 

In your case, many packets are sent per connection event. You could consider reducing the connection interval to around 30 ms or less and see if the situation improves.

In order to confirm throughput reduction or sniffer problem, consider using the log from both sides.

Best regards,
Dejan

[EthanJia]

Hi Dejan!

Thanks! Yeah I think you are right. After adding all the ATT MTU packet sizes and comparing with the theoretical sum, I found that the sniffer actually missed lots of packets. Hence, the multiple ACKs should be caused by Sniffer's misses. Is this common for the Sniffer to lose track of so much packets?

Meanwhile, my project is very time-critical, so are there any methods to disable ACKs in the Link Layer? I suppose for each connection interval without ACKs, there would be at least 344μs saved. Although right now the ATT layer ACK is disabled by using notifications instead of indications, the LL will automatically send ACKs.

Best regards,

Ethan

[dejans]

Hi,

EthanJia said:

Is this common for the Sniffer to lose track of so much packets?

It is not common for the sniffer to lose many packets. Since you have some issue with a sniffer, consider swapping DKs or replacing sniffer with a new DK. Please let me know whether you still experience drop in the throughput.

EthanJia said:

Meanwhile, my project is very time-critical, so are there any methods to disable ACKs in the Link Layer?

There is no way to disable ACKs in the link layer in the SoftDevice.

Best regards,
Dejan