nRF9160 MQTT responses time

[yesheng]

Hi,

I'm using nRF9160 to send data to AWS via MQTT publish every second. Normally, the nRF9160 responds with "OK" almost instantly when I send the AT command, however, it takes more than 1 second to send "OK" from time to time. I'm wondering how can I improve this latency.

Thanks,

[Didrik Rokhaug]

Hi,

How much data are you sending?

Depending on your link quality and how much data you are sending, it might be that the modem isn't always able to send the data fast enough, causing send() to block until the memory buffer becomes ready again.

One thing you can try to reduce the latency, is to increase the buffers controlled byt eh Kconfig options found in this Kconfig file: nrf/lib/nrf_modem_lib/Kconfig.modemlib

Best regards,

Didrik

P.S. Due to holiday vacations, response time might be longer than normal. We apologize for the inconvenience.

[yesheng]

Hi Didrik,

I'm using the SLM FW (SDK: 2.0.2), and I'm sending ~1KB/s. I tried to double the size of CONFIG_NRF_MODEM_LIB_SHMEM_TX_SIZE but it doesn't seem to change anything. 

The RTT log shows a gap between Raw send and datamode off pending. that's the place I saw the modem's slow responses.

for reference, this is the normal situation, only 3 ms delay between raw send and datamode off pending

Thanks,

[Didrik Rokhaug]

Did you also try to increase CONFIG_NRF_MODEM_LIB_HEAP_SIZE and CONFIG_NRF_MODEM_LIB_SHMEM_CTRL_SIZE?

How often or consistent is the gap?

Could you also enable logging in the MQTT library, and send me the log?

CONFIG_NET_LOG=y

CONFIG_MQTT_LOG_LEVEL_DBG=y

(and, if you haven't already, enable debug logging in the SLM itself).

[yesheng]

Hi Didrik,

The log shows the client_write_msg takes an unusual amount of time to finish. Normally, it takes less than 10 ms to finish writing 1 kB of data.

I've increased the CONFIG_NRF_MODEM_LIB_HEAP_SIZE, and it seems to reduce the frequency. I'll keep monitoring.

Thanks,

[yesheng]

Update:
With more testing, I think this phenomenon is more of a temporal thing. These events tend to happen consecutively. Perhaps signal strength plays a more critical role.

[Didrik Rokhaug]

That would match my suspicion in my first reply.

Have you tried to monitor the signal strength and other connection parameters to see if there is a correlation?