Very high response times of reliable unicast messages.

[Armin]

I adapted the light switch demo of the nRF5 SDK for Mesh for sending a series of reliable on/off messages sequentially from an nRF52840 Preview DK to 20 Thingy:52 servers via send_reliable_message(). In this scenario I measure in most cases response times between 20 to 50 milliseconds, which is quite acceptable. However in about one of 20 cases there is a significant higher response time of many seconds. It seems that the delay in this cases is always a multiply of 5 seconds, so I get 5, 10, 15 and so on seconds response time in these cases. Is this a normal behavior of the stack, and do I therefore have to accept these sporadic long response times? Or is there maybe a parameter which can be tweaked in order to get a better performance with reliable messages?

[tesc]

Hi,

Thank you. That it is in fact a doubling is very interesting, and it supports the hypothesis. I will try once more to reproduce, and check to see if changing parameters may improve the situation.

Regards,
Terje

[tesc]

Hi,

Revisiting this one, after a (way too long) silence from my side.

I do have a couple of suggestions.

The first one is to update to a newer release of the nRF5 SDK for Mesh. We have experienced that especially with the proxy feature enabled you may experience packet loss because of the parameters chosen for advertising and connections. If I recall correctly then default settings were changed slightly for the current release (v2.2.0) and from what I understand there will be further improvements for next release.

The time between retransmits depend on TTL. A shorter TTL setting means shorter time between retransmits. The values that you have experienced for the delay correspond to a relatively high TTL setting.

You could also experiment with the ACCESS_RELIABLE_INTERVAL_DEFAULT setting, which is also proportional to the time between retransmissions. There is also the ACCESS_RELIABLE_BACK_OFF_FACTOR which makes each consecutive retransmission delay more than the previous, with that factor. Defaults to 2, which means you see a doubling in delay for each retransmission.

And of course, if you have found out anything in your end then please feel free to share your findings.

Regards,
Terje