MQTT Interval weird queueing STM32 nucleoF767ZI

[MLGino]

Hello everyone.

I am working on a project with a nucleoF767ZI nucleo board. In this project I want to send MQTT messages every 100 milliseconds. However, when I use any kind of timer, it queues the messages and they get send every 500 milliseconds.

I use the umqtt library from https://github.com/micropython/micropyt ... qtt.simple, but have tried the one from https://github.com/fizista/micropython- ... ple_sub.py as well.

When I use

Code: Select all

while True:
	client.publish("foo_topic", "hello")

I get a steady stream of messages, however, this is way to quick for my requirements.

When I tried either of the three following, they get queued, and sent around every 500ms, resulting in 10 messages coming in at once:

Code: Select all

lastTime = 0
while True:
    if(ticks_ms() > lastTime + 100):
        client.publish("foo_topic", "hello")
        lastTime = ticks_ms()

Code: Select all

def sendMessage():
    global client
    client.publish(b"foo_topic", b"hello")

def tick(timer):                # we will receive the timer object when being called
    print(timer.counter())      # show current timer's counter value
    micropython.schedule(sendMessage, "timer")

# create a timer object using timer 4 - trigger at 10Hz
tim = Timer(4, freq=10, callback=tick)

Code: Select all

lastTime = 0
while True:
        client.publish("foo_topic", "hello")
        utime.sleep_ms(100)

Does anyone have any idea to what would cause this behaviour.

[pythoncoder]

Are you sure it's not the broker that's queuing the messages? I suggest you do this to prove it either way:

Code: Select all

def sendMessage():
    global client
    client.publish(b"foo_topic", f"hello {time.ticks_ms()}".encode())

[MLGino]

I tried your method. The timestamps in the messages are indeed with 100 ms interval. However, that still does not prove if it is necessarily the broker or stm right? Since they do not get queued once the delay/interval is removed. To validate, I made a python script that also sends messages at the same frequency and those do get received at the correct interval.

[karfas]

There is way too less information in the original post.

How exactly did you find out the messages get queued somewhere ?
Do you use a mqtt broker on your local net ?

You might use a packet sniffer (e.g. tcpdump, Wireshark) to rule out your board (and micropython) as the cause of the observed behaviour.

Also note that neither MQTT nor TCP guarantee delivery of your messages within a specific time frame. They usually work fast enough for your 100ms intervals, but might also delay the messages for seconds or minutes.

[pythoncoder]

I don't believe umqtt.simple is capable of queueing - I suggest you look at the source to see if you agree. However it is possible that something is going on in the (firmware) socket implementation; the suggestions of @karfas would prove this one way or the other.

I'd question whether MQTT is generally viewed as being suitable for realtime applications. The test I suggested shows that it is capable of sending data in a timely fashion, but I don't know if you can expect a low-latency path from the sender, via the broker, to the receiver. You certainly can't if the broker is on the internet. I have tested one mqtt_as client controlling another via a local broker. There was visually detectable latency but I never actually measured it. Of course some of that latency might be down to my asynchronous coding, something that doesn't apply to umqtt.simple.

[MLGino]

Sorry for not explaining everything in the first post. The STM is directly connected to my PC via an ethernet cable. I have a mosquitto broker running on the PC. Nothing else is using that broker or ethernet connection.

How I found out about the problem
I first just looked at the command line output of the mosquitto broker with the -verbose option. In there it already seemed to stutter, instead of being delivered every ~100ms, so to check, I made two python scripts on my laptop, one that receives the messages and prints the message, together with the current time, and another to validate it is not the broker, that sends messages every 100ms.

When I use the two python scripts, the messages get correctly send and received every 100ms, when I use the STM to send, with the 100ms delay or timer, I receive 5 messages at once every ~500 ms.

I used wireshark to check as well, and in wireshark is that a group of packets are sent around the same time, and then there is around 500 ms before the next group of messages.

https://gyazo.com/efe70e87bc60d50ee0e888989ee970e0 (Image of wireshark output)

What confuses me
I understand MQTT may not be the best option for a fast data communication, since it is built upon TCP, however, when I remove the timer/delay in the STM code, I get a very constant supply of messages, without any delay between them (2 per millisecond).
So I think that completely rules out that is could be a broker problem.

umqtt.simple does indeed not look capable of queueing, so then it might be the socket implementation? I do not have enough knowledge in this field, so if you have any ideas what to research further, I would gladly hear it.

[pythoncoder]

I think wireshark proves it's the socket, but short of studying the socket source I don't know what to suggest.

[karfas]

Thank you for the additional information.
Now we can be pretty sure that the problem is really related to the board and/or micropython.

Unfortunately, I can only recommend to raise this issue in the github issues.
Most likely, it will sit there for months or years (as a maybe related https://github.com/micropython/micropython/issues/7039).

What confuses me
I understand MQTT may not be the best option for a fast data communication, since it is built upon TCP, however, when I remove the timer/delay in the STM code, I get a very constant supply of messages, without any delay between them (2 per millisecond).

You are observing a queue.

I imagine that you fill the buffer quickly with your first messages; following socket.write() calls will have to wait until there is enough space in the buffer again. Enough space becomes available when at least one message has been sent out. Provided your messages are of similar size, the TCP stack is busy sending out older messages when you add a new one, so you get a continous stream...

[pythoncoder]

@karfas That certainly seems to describe how it behaves at high throughput. But if you send a single MQTT message and wait, the message does get sent - it would be interesting to measure that latency.

The behaviour seems to be that a message gets queued. If another message gets written within that latency period, that gets queued. But if nothing is written for more than that time, the queue gets flushed. The queue also gets flushed if it becomes full.