Initialization of subscribe and publish very slow (delay) (CA-248)

[law-ko]

Hello,

We have realized the initialization process of subscribing and publishing is very slow and is due to the delay between each subscribe when the device first boots up. Is there any way to decrease or speed up the process?

I (45089) DeviceShadow: SUBSCRIBE topic $aws/things/thing_name/shadow/delete/accepted to broker.
I (45259) coreMQTT: Packet received. ReceivedBytes=3.
I (45259) DeviceShadow: Received SUBACK.

{{delay is here}}

I (48259) DeviceShadow: SUBSCRIBE topic $aws/things/thing_name/shadow/delete/rejected to broker.
I (48429) coreMQTT: Packet received. ReceivedBytes=3.
I (48429) DeviceShadow: Received SUBACK.

Thank you

[SolidStateLEDLighting]

Can you put a measurement on your observation? What exactly are you seeing in terms of "slow"?

[law-ko]

From the data log it is showing there’s a delay of 3000 ticks, which is around 3 seconds.

[SolidStateLEDLighting]

How are you calling the MQTT_ProcessLoop() function. Are you applying a long wait time there?

[law-ko]

The MQTT_ProcessLoop function is the same as in the example shadow thing project. It is called here

[SolidStateLEDLighting]

So, I think we can see where you are getting 3 seconds. Notice that MQTT_PROCESS_LOOP_TIMEOUT_MS has a value of 1500mS.

Your first wait is sending the outgoing message and your second wait is receiving the response.

The examples which show how to run the libraries are not optimized for performance. They are just working examples -- and they work.

Now it is up to you to change the call to MQTT_ProcessLoop so you wait a little as possible -- and you'll have what you need. You can't just put small numbers in there and expect success because if you don't wait long enough, you might not see your response message. Sadly, that will mean re-writing that routine extensively to pass through MQTT_ProcessLoop with a timeout of 0 and handling any response you might receive at any time. (remember, nothing happens without going through MQTT_ProcessLoop) So, set your endless loop and fit all your other calls in there correctly and the job will be done).

[law-ko]

Changing MQTT_PROCESS_LOOP_TIMEOUT_MS to 1000U or 200U does not change the delay between subscribes. The data log still shows 3000 difference.

Are there other parameters that need to be taken care as well?

[SolidStateLEDLighting]

Then that is what subscribing takes in this case. Try to subscribe and unsubscribe sparingly.

You may also notice that subscribing has a fault catching routine. You might want to examine that to see if the backoff algorithm is in play and repeating your subscription process for some unknown reason.

[law-ko]

Do you mean that subscribing and publishing requires 3000mS to finish? If you look at the data log the delay is after the subscribe receives the SUBACK, which I don't think (or don't know why) it requires another 3000ms wait to start for the next subscribe.

[SolidStateLEDLighting]

You need to write the code which does what you want without any delay. Stop relying on this sample code which is just there to prove the concept. Once you have a response of any kind, you may immediately send another message of the appropriate type and the MQTT_ProcessLoop will seek out the next response as needed. I'm telling you again -- don't put any wait time in there and you'll get the shortest wait by default (with success or failure possible). I think my experiments showed about a 1/2 second wait time under all conditions where my hardware was negotiating an AWS connection from around the world. If you have this timeout variable set to MQTT_PROCESS_LOOP_TIMEOUT_MS then you can expect a 3 secs turn around time for each published message which receives an answer. If you shorten it -- you may not receive the answer -- thus my suggestion for a re-write to loop which endlessly calls MQTT_ProcessLoop (time of of zero) with the correct state-transition written code behind it to support capturing all your responses as they do arrive in their shortest possible time.

[law-ko]

Changed MQTT_PROCESS_LOOP_TIMEOUT_MS to 0U to shorten subscribe and publish time