Maximize BLE Throughput?

[vChavezB]

I have been testing over Windows and I am getting about 3 kB/s upload where as with NRF Connect Android app ~11 kB/s.

So I was wondering if there is anything I can do to maximize the throughput on the smpmgr/smpclient side.

[JPHutchins]

Since BLE isn't added to smpmgr, I imagine this is via smpclient?

Generally, I see between 15-20kB/s on Windows, 25kB/s on MacOS, but it relies on a few things:

• FW is configured for the 498 MTU
• 498 MTU negotiation occurs correctly - this is something that we've attempted to work towards in Bleak. Enabling debug logs can reveal the actual MTU.
• FW is configured for the SMP messages of size 2475. This relies on 5 buffers of size 495 to reassemble the SMP messages.

These FW configurations are based on Nordic's "fast OTA DFU example". In fact, sample FW and configurations are present in the smpclient repository dutfirmware folder. The examples folder runs hardware integration tests, and the one for BLE upgrade will:

• flash example FW
• connect over BLE
• upload new FW
• request swap and reset
• verify that swap was successful

If that script shows slow speeds then it's likely a limitation of the drivers.

[vChavezB]

MCUMGR params will enable smpclient to acquire the netbuf size from the FW when it connects. It would be interesting to know what netbuf size and MTU is getting negotiated. I suspect netbuf size is OK but MTU is 20 bytes instead of 498.

Ah ok I get it. Based on the mcumgr parameters the smp client knows the largest size of the packet, 2475 bytes in this case.

[JPHutchins]

It all looks correct! Smpclient is fragmenting messages of size 2475 into the MTU of 495 for good speed.

Unfortunately, because then the slowness is either the FW or the windows driver.

[vChavezB]

Thanks a lot ! Well I will do some more tests on linux.

[JPHutchins]

Looking at the logs again, it's taking a surprising amount of time for the FW to respond to the upload request:

2024-08-04 21:46:24.793 DEBUG    Sent 2475 bytes
2024-08-04 21:46:24.793 DEBUG    Waiting for notify on SMP_CHARACTERISTIC_UUID=UUID('da2e7828-fbce-4e01-ae9e-261174997c48')
2024-08-04 21:46:29.102 DEBUG    Received 17 bytes from SMP_CHARACTERISTIC_UUID=UUID('da2e7828-fbce-4e01-ae9e-261174997c48')

There's over 4 seconds between the request and response. This is sometimes expected for the very first packet, since the FW may do a mass erase of the upload slot before responding, but it would be something to look into if all of the responses take this long.

[vChavezB]

You are right, the first request erases an external Flash SPI NOR partition. This only happens for the first request. I will try to run the command again to verify timing of subsqeuen requests.