Access_model_reliable_publish and acknowledge, retries

RE: Access_model_reliable_publish and acknowledge, retries

Mttrinh — Wed, 22 Jan 2020 12:48:27 GMT

Hi,

Sorry for the late response. I have talked to one of our developers and this is his response to the issue:

I see why the customer is facing the issue. He uses the 30 Byte long messages and uses the "acknowledged transfer" API. In a case when he uses the acknowledged transfer API, he is sending these messages to a Group address. When SAR transfer is triggered to the group address, according to the specification there will be no block acknowledgements to the SAR message segment (Note that these transport layer block acknowledgements are different than the access layer unack/acked message classification). Therefore, the nrf mesh stack will retry 4 times (i.e. TRANSPORT_SAR_TX_RETRIES_DEFAULT) before declaring the SAR transfer completion. It takes about 4-5 seconds to finish this process, it will take longer, if the message is bigger. Therefore, customer sees that he cannot initiate new SAR message earlier than 4 seconds to the same destination.

How does he see things working differently for unacknowledged messages?
The SAR mechanism does not distinguish if the message being sent is acknowledged or not at the model/access layer. Therefore, the SAR transfer for unacknowledged model messages to the Group destination should work exactly like that of acknowledged model messages. Therefore, he should see the same ~4 second waiting period before he can trigger another unacknowledged model message. I verified this by on desk experiment. Now, since this does not happen in customer's case (he is reporting much better performance for unacked messages), then the destination for these unacked messages is not a Group address (I suspect that these unacked messages are being sent from another client instance which is publishing to a Unicast address). If the destination is Unicast, the SAR transfer will succeed as soon as full transport layer block acknowledgement is received from the destination node thereby unblocking the transport layer for accepting further SAR messages to the same destination.

In summary, if a customer wants better throughput while delivering data to the group, it is better to use model messages that will fit into single segment. For a reference, see Table 3.42 in Mesh Specification v1.0.1.

RE: Access_model_reliable_publish and acknowledge, retries

Amadeus — Fri, 13 Dec 2019 19:02:24 GMT

Yes, and I am calling that function before access_model_reliable_publish() and get no "Acknowledged transfer canceled" log in the above snippet, therefore, the problem should not be that I am sending messages to fast.

RE: Access_model_reliable_publish and acknowledge, retries

Mttrinh — Fri, 13 Dec 2019 16:10:34 GMT

Yes, if access_model_reliable_cancel() is called it should cancel an ongoing reliable message.

RE: Access_model_reliable_publish and acknowledge, retries

Amadeus — Thu, 12 Dec 2019 15:27:45 GMT

I can try that, but I am able to send unacknowledged messages MUCH faster, so I really don't think that is the problem. Furthermore, shouldn't access_model_reliable_cancel() cancel ongoing packets if I was sending messages to fast?

RE: Access_model_reliable_publish and acknowledge, retries

Mttrinh — Thu, 12 Dec 2019 14:20:09 GMT

Just to be sure that you don't send messages too fast you should wait for the NRF_MESH_EVT_TX_COMPLETE before sending a new message.

[quote user="Amadeus"]I have not changed the retry interval of reliable publish, where can I do that?[/quote]

You can change it using the define ACCESS_RELIABLE_RETRY_DELAY found in the access_reliable header file.

RE: Access_model_reliable_publish and acknowledge, retries

Amadeus — Wed, 11 Dec 2019 09:01:35 GMT

This happen when I regularly send acknowledged messages more often than around every 4 seconds.

Above is a snippet from RTT viewer. Here, I have logged the return value of packet_alloc_and_tx() inside access_model_publish(). As you can see, this time the function is called five times before the message is acknowledged. Sometimes, some of these status messages show and 8 (NRF_ERROR_INVALID_STATE) instead of 0, but continues till ack is received.

Edit: To clarify, I am not calling access_model_reliable_publish multiple times above, it is called automatically by the API.

My messages are between 20 and 30 bytes and indeed segmented, but it should not take a long time to send those. I have not changed the retry interval of reliable publish, where can I do that?

RE: Access_model_reliable_publish and acknowledge, retries

Mttrinh — Tue, 10 Dec 2019 15:23:16 GMT

Hi,

Sorry for the late response on this,

How often does this happen? How big is you packets and how fast do you send them?

access_model_publish() returning NRF_ERROR_INVALID_STATE means that there is already a segmented packet to this destination in progress. Wait for it to finish before sending new segmented packets.