ble_app_att_mtu_throughput: throughput calculation, packets per interval, Data Length Extension

[homeslashbjrn]

Just stumbled upon a few questions, which are hard for me to answer at the moment.

I wanted to do some throughput measurements with the example taken from SDK 14.2.0 mentioned above on two nRF52840 DKs, which are using SoftDevice S140. My first plan was to calculate the theoretical throughput by (1000ms/<Connection Interval>) * 20 bytes * 8 bits/byte * <Packets per Connection Interval> and compare it with the measurement.

Another possibility is to use the way seen here. He is calculating the time to transmit a data packet (296bits/1Mbps), an empty packet and the time for a complete packet transfer (<time for data packet> + <T_IFS> + <time for empty packet>). After that, you can divide this time by the Connection Interval, what then leads to the technical maximum transfer "cycles" in one connection interval, which are higher than the numbers stated in SoftDevice Specifications. I got confused by his first example, where he has chosen (att_mtu: 23, conn_interval: 7.5, dle: on, phy: 1M). The result was about 232kbps and his calculated value 234kbps with an assumption of 11 packets per Connection Interval. With the same values, I am getting a throughput of 86kbps (first run) and 128kbps (following runs). These values seems to fit my first attempt to calculate the throughput. On the first try, a number of 4 packets and on the second try, a number 6 packets are transmitted, as these are multiples of ((1000ms/7.5ms) * 20 bytes * 8 bits/byte = 21.3kbps>).

So, my questions are:

1. The SoftDevice Specifications for S132 (v5.1, p.56, Table 27) are giving the numbers of maximum packets per Connection Interval. Is there an equal information for S140 or are they the same in this regard?
2. Why is the first test run different from the subsequent ones? Is the maximum number of packets per interval negotiated on the first run? But: the results are not always different for some settings.
3. I wanted to "simulate" the throughputs of v4.0/v4.1, v4.2 and v5.0. So, I disabled Data Length Extension (DLE) for v4.1. A "definition" is given this blogpost:

Data length extension (DLE): This will set the on-air packet size. The maximum on-air packet size is 255 bytes. If we take away L2CAP header (4 bytes) and Link Layer header (4 bytes) we are left with an ATT packet of 247 bytes. For simplicity in this demo, you can turn DLE either on or off. If DLE is on, the size will be set to the ATT packet size plus the header bytes. This will avoid fragmentation of the ATT packet into several on-air data packets, to increase data throughput. DLE will affect the throughput greatly as larger packets will lead to more time sending actual data.

I am getting a throughput of ~128kpbs (att_mtu: 23, conn_interval: 7.5, dle: on, phy: 1M) and ~238kbps (att_mtu: 23, conn_interval: 7.5, dle: off, phy: 1M). Shouldn't be both of these measurements be the same? Why is there an influence by the DLE disabled with ATT MTU of 23 Bytes?

4. Am I right, that the Connection Length Extension is kind of "levering out" the maximum number of packets per connection interval if it gets longer than a few milliseconds? If I understood it correctly, with CLE enabled the device will continue sending packets until a next interval/event is scheduled to save overhead.

Thanks and regards, Björn

[Petter Myhre]

1. It does, when radio notification is enabled. When radio notification is enabled it will reduce the maximum number of packets exchanged:

The SoftDevice will limit the length of a Radio Event (tradio), thereby reducing the maximum number of packets exchanged, to accommodate the selected tndist.

When the radio notification is disabled the maximum throughput is listed here. These are measured values, 192 kbps means that 9 packets is transferred every connection interval.

2. I don't really know why you get that result, I think you will have to provide some more information on what exactly you are doing.

3. As long as you have an ATT MTU of 23 DLE shouldn't matter. Again, I need some more information on what exactly you are doing to answer why you get 238 kbps.

4. Correct.

[homeslashbjrn]

With att_mtu = 23, phy = 1M, conn_interval = 7.5 and dle = off I am getting a throughput of 171.91 kbps. As mentioned before, in amts_evt_handler() on NRF_BLE_AMTS_EVT_TRANSFER_1KB I have added debug output for counted radio notification events. The number of radio events after 1020 or 1040 transmitted bytes is about 6 or 7 (independent of bytes sent). Which gives around 145.7 to 173.3 bytes per radio event, but actually I expected a multiple of 20 bytes (with att_mtu = 23 and dle = off). Nevertheless, when I disable the radio notifications, the throughput is now 192.4 kbps, as you mentioned in 1). Of course, this was the reason for the low throughput of 64.5kpbs. So, with radio notifications disabled the measurements with dle off and on are:

att_mtu, conn_interval, dle, cle, phy, throughput
23, 6, o̶f̶f̶ on, on, 1, 85.93
23, 6, o̶n̶ off, on, 1, 192.4

From that I conclude, that e̶̶n̶̶a̶̶b̶̶l̶̶i̶̶n̶̶g̶ disabling the data length extension will increase the number of packets transmitted from around 4 to 9. Which also equals your statement in 1). However, it is not clear for me, where the number of 4 packets comes from. In table 27 of S132 SDS v5.1 at tndist = 800 and conn_interval = 7.5 the packet transfers are stated with 6.

edit: I've corrected the mistakes I made by twisting the values of my measurements as I wrote the comment…