• State Not Answered
  • Replies 17 replies
  • Subscribers 73 subscribers
  • Views 4991 views
  • Users 0 members are here
Attachments (2) Download All
Nordic Case Info
  • Case ID: 211312
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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?

Parents
  • 0

    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. 

  • 0 in reply to Hung Bui

    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!

  • 0 in reply to Armin

    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 ?

Reply
  • 0 in reply to Armin

    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 ?

Children
Related
Terms of service