Trying to achieve higher throughput

[rench9]

Hey, we are trying to exchange audio stream over mesh and testing the throughput on NRF 52840 DK.

Modification we tried to achieve higher throughput:

• For testing we are sticking to only 2 nodes
• Min and Max Connection interval to 7.5 ms from BleGapConnect method
• Updated the MTU to 247
• Changed the MAX_MESH_PACKET_SIZE to 244
• Modified the MESH_CHARACTERISTIC_MAX_LENGTH to 244
• We ensure that the stack buffer is always full and for every failed request we retry after *GattDataTransmittedEventHandler** call
• We also tried decreasing the MAIN_TIMER_TICK from 2ds (6554) to 1ds (3277)
• We achieved max throughput around 170 kbps with data size of 200bytes and as we increase data size to 240bytes throughput comes down to 120 kbps

Note: With NRF throughput example code we are getting around 262 kbps with 1MB PHY and connection interval 7.5ms. With connection interval 15ms we are getting around 490kbps

How to attain higher throughput with fruity mesh same as NRF throughput example code?

Reference to NRF throughput example code: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_nrf5_v17.0.2%2Fble_sdk_app_att_mtu.html

[mariusheil]

Hi,

technically, you should be able to get the same throughput with FruityMesh than what you get with the nrf sdk. There might be some overhead due to the way how packets are handeled and queued, but I would guess that this should be minimal enough to always keep the SoftDevice buffer full. I would guess that the most probable cause is, that the buffer of the SoftDevice was not always filled up and that there were times where no data was sent. Filling the data from the TimerEventHandler would probably not be enough as it is not guaranteed to trigger often enough, so you could e.g. try by registering a MainContexthandler.

Did you do the throughput tests with the same SoftDevice version? That would be necessary to properly compare the two implementations.

Be aware that creating a mesh with multiple nodes will decrease the througput as there is quite a bit of overhead due to the concurrent handling of peripheral and central nodes.

Marius