IoT Hub does not allow near real time messaging

Martin Jørgensen 36 Reputation points
2020-12-02T08:40:58.667+00:00

We are using IoT Hub in a scenario, where near real time communication is required.
We define near real time communication as less than 2 seconds for a message loop (C2D -> D2C).
We have observed, that even though we are running emulated devices on a virtual server located in Azure data center, some messages are still requiring 10 seconds or more for delivery. Most of the messages are completed in 400ms.
What is causing the huge difference in delivery time, and what can be changed?
Is IoT Hub useable for any near real time communication?
The Microsoft comment: "Avoid making any assumptions about the maximum latency of any IoT Hub operation" (https://learn.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-quotas-throttling#latency) does not sound promising...

Thanks
Martin

44372-image.png

Azure IoT
Azure IoT
A category of Azure services for internet of things devices.
377 questions
Azure IoT Hub
Azure IoT Hub
An Azure service that enables bidirectional communication between internet of things (IoT) devices and applications.
1,112 questions
{count} votes

Accepted answer
  1. António Sérgio Azevedo 7,661 Reputation points Microsoft Employee
    2021-05-03T06:48:55.433+00:00

    Hello @Martin Jørgensen ,
    Thank you so much for your time in the Azure Support Ticket. I am now posting our conclusions and would appreciate if you can verify this as the answer or add any other comments for further explanation.

    When analyzing more carefully the logs you provided we realized that two messages in a row never took more than 1 second to be delivered - which is a totally acceptable behavior. The strategy to overcome that is to send the message again if no ack is received after 1 second (or based on any other benchmark for retry interval you define on your own). We do already have a document on no guarantees around the message delivery latency - Reference - IoT Hub quotas and throttling#Latency | Microsoft Learn - and as expected the retry period (example: 1 second if no ack) would vary depending upon many factors, including device’s network connection and device’s processing. Note that, if we setup a very aggressive retry policy we may be throttled, so there needs to be a balance and delay expectations should be well set in customer experience design.

    Thank you so much for these great questions and we hope we have provided you the right tools to proceed with your development.

    Remember:

    • Please accept an answer if correct. Original posters help the community find answers faster by identifying the correct answer. Here is how.
    • Want a reminder to come back and check responses? Here is how to subscribe to a notification.
    1 person found this answer helpful.

2 additional answers

Sort by: Most helpful
  1. Sander van de Velde 28,236 Reputation points MVP
    2020-12-02T09:41:21.96+00:00

    Well, if the internet connection is lost, the delivery times will be even larger ;-)

    My impression is that the IoT Hub is built for scalability and reliability. Though, the waiting times of 10 seconds seem strange.

    Did you look at the partition setting already? Under the covers, the number of parallel processes is set with this setting:

    44392-image.png

    If you rely on sub-second response times, please consider an Edge solution where the cloud logic you use to make decisions, is put on an edge device. This takes out at least the internet component of your roundtrip.

    Update: Check for the nearest region for the IoT Hub (lowest latency)

    0 comments No comments

  2. Martin Jørgensen 36 Reputation points
    2020-12-02T10:12:40.267+00:00

    At the moment the IoT Hub only handles a few messages per second, so it should not be a load issue.
    We are using "S1 - Standard" and 4 partitions.
    The test setup I have made is using the IoT Hub directly, without use of Azure function triggers etc.
    Our complete solution involving several EventHubs/ServiceBusses etc. shows additional latency.
    Often the latency in each "message" component in Azure is about 1 second!!! And other times it is perhaps 100ms.
    And we have observed even higher delays in "message" components, but Microsoft reply that is just because we are using a "shared ressource", and someone else in Microsoft infrastructure put pressure on "message" components.
    The sub-second is definitely not something you can rely on (except if you go for single-tenant deployments. Have not tested it...)...

    Our solution is based on a customer initiating an operation on a device. Like turning on light. That functions is difficult to implement as an edge solution...
    And it does make a difference, if the light turns on in 1 second or 10 seconds.