What is the max data throughput with S132 v3?

[jmc]

The absolute max throughput for the nRF52 using S132 v2 was 128 kbps.

The new S132 v3 was recently released and boasts throughput increases by 400%. Has anyone tested this and found the actual max throughput rather than an estimate? Is there example code for testing this?

[Ulrich Myhre]

Internally I have been able to reach speeds just shy of 800kbps, and over that if you look at the raw L2CAP traffic.

To reach the maximum throughput, you need a peer that also supports Data Length Extensions. The length of these should be configured so that it is 4 bytes longer than the ATT MTU size, so that the full packet (including 4 bytes of L2CAP overhead) fits into a single packet. Example values could be an ATT MTU of 247 and a DLE size of 251. Additionally, there is a possibility to enable extended connection events, which will boost the throughput a lot when on a single connection. This simply lets the softdevice keep the connection event running until the next event, or until the peer NACKs a packet.

Mini-guide on how to accomplish this:

1. During SoftDevice enable, set enable_params->gatt_enable_params.att_mtu to 247.
2. Set DLE size with sd_ble_opt_set(BLE_GAP_OPT_EXT_LEN, &opt) where opt.gap_opt.ext_len.rxtx_max_pdu_payload_size = 251 (This step should be optional, but if DLE has been disabled earlier it has to be done).
3. Enable event extension with the options API. sd_ble_opt_set(BLE_COMMON_OPT_CONN_EVT_EXT, &opt) where opt.common_opt.conn_evt_ext.enable = 1.
4. Establish a connection as normal, preferably with a very long connection interval, and initiate an MTU exchange using the relevant APIs. The SoftDevice will automatically initiate DLE negotiation after the MTU exchange has completed. If successful, this produces an extra event stating that the data length was increased.
5. Send longer data packets than before. Remember that for notifications and write commands, 3 bytes are lost in overhead. This means you should be able to segment your data into ATT_MTU-3 = 244 byte payloads.

Keep in mind that long link layer PDUs are more sensitive to noise, as they take longer to transmit. Some peers might limit both ATT MTU and DLE sizes, so it is had to say exactly what you should expect when not testing nRF52 vs. nRF52.

[jmc]

Actual data throughput with overhead removed was almost 800 kbps? Wow!

[Ulrich Myhre]

By "raw L2CAP traffic" I meant inlcuding ATT headers and L2CAP headers. Not counting preamble, access address and other baseband parameters. Actual user-defined ATT data traffic is slightly lower, but it should be in the same ballpark - i.e. around 775kbits depending on noise and connection parameters. Very long connection intervals are better with extended connection events, because the SoftDevice can keep on sending without spending time opening/closing events.

[djqtsg]

Are there any other parameters that need to be changed, like NRF_BLE_MAX_MTU_SIZE?

I am using UART sample code to test DLE feature. If I change NRF_BLE_MAX_MTU_SIZE to a bigger size than GATT_MTU_SIZE_DEFAULT, the app_ram_base should also be changed accordingly; otherwise softdevice_enable() returns error.

In the UART sample code, I cannot find where sd_ble_opt_set() is called. So if I want to call it, where should I do, in softdevice_enable()?

[Ulrich Myhre]

I work more on the SoftDevice directly than through the SDK, but if that define is used in the att_mtu field it should be updated. Outside of the things I mentioned (ATT_MTU, rxtx_max_pdu_payload_size, conn_evt_ext.enable) nothing else needs to be done, except initiating the MTU exchange procedure once the link is set up.

sd_ble_opt_set() for setting DLE size should be set after enabling the stack, but before going into a connection. It might not be needed in some cases, as it should default to ATT_MTU+4 automatically. Increasing MTU size will indeed change the memory requirements, as the stack needs larger buffers to reassemble the PDUs.