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?

[Hung Bui]

Hi Armin, 

No I don't think it's a normal behavior. Do you see the same problem when you test with unmodified version of the light switch examples ? 

Do you see the same problem if you have less number of nodes ? 

 

Did you run anything else beside mesh on the node ? Running BLE or proxy on the node would affect the mesh performance. 

 

The mechanism to resend notification is similar to trickle algorithm the interval is multiple by ACCESS_RELIABLE_BACK_OFF_FACTOR by each retry. But your 5-10-15 seconds observation is quite strange, wouldn't match with what we have. 

Which TTL value did you set ? The timeout is calculated by the TTL value. 

Did you send the reliable message to a unicast address or to a group address  ?

Also do you see the packet arrive on the peer device before that 5 -10 .. seconds ? We need to find if it was the original packet missing or the response packet missing. 

[Armin]

The behavior is independent from the number of nodes. I tested with 3, 5, 20 and 30 nodes.

The messages are sent from the light switch client node, which runs on the nRF52840 Preview DK with project light_switch_proxy_client_nrf5284_xxAA_s140_6.0.0. By that it is also the proxy for commissioning via Smartphone. All server nodes running on Thingy:52 with project light_switch_proxy_server_nrf52832_xxAA_s132_6.0.0, so all servers are also proxy.

The TTL value is the default set in nrf_mesh_config_app.h #define ACCESS_DEFAULT_TTL (SERVER_NODE_COUNT) whereas SERVER_NODE_COUNT is set in light_switch_example_common.h as #define SERVER_NODE_COUNT (30)

The reliable messages are sent to a unicast address. Group addresses can only be used with unreliable messages!

Yes, the packet arrives at the servers always very fast. An LED is switched on there when the message arrives and I see almost no visual delay between the time the message is sent which is indicated by a log output at JLink Viewer and the LED lights on. By that the high delay comes actually from the response!

[Hung Bui]

Hi Armin, 

I guess the proxy feature could be the cause here. When you see the issue, was it with the phone connected or not ? If it's connected to the phone, we need to check the actual connection interval. 

If it's not connected to the phone, we need to check the advertising interval of the client and also the advertising interval of other server nodes. 

We want to test and reproduce the issue here. How did you test ? Did you simply just send reliable message to one single node or to multiple nodes (with multiple messages) ? You mentioned you can see it once in about 20 trials ?

[Armin]

It makes no difference whether the Smartphone is connected or not.

You mention you have to check the advertising interval. Please tell me exactly which parameter I shall provide to you in case.

I'm sending multiple reliable unicast messages to multiple nodes. After each send I wait for the reply, wait an additional time (200ms) and then send the next.

I could attach the source here if it helps.

[Hung Bui]

yes, please attach the code. 

You can use a phone to see the advertising interval (nRFConnect app)