Sending MQTT messages at regular intervals on a PC

[e100]

Under regular Win/Linux is it possible to send a MQTT message every 50 milliseconds with no more than 10 milliseconds of jitter?
Or is this going to be impossible?

Currently I'm testing my PC based data processing system by sending itself dummy test data and sometimes the regularity of the outgoing data gets so bad that my incoming processing algorithm thinks that the flow of messages has stopped, and therefore flags an error. I could of course just increase the timeout, but then it wouldn't be mimicking the behavior of the real system that is designed to work with microcontroller based sensors that send MQTT messages at regular 50 millisecond intervals.

[mianos]

I have some devices that send data 20 times a second (radar ranging). There is a lot of jitter between the sender, the mqtt broker and the receiver. What I do is timestamp the outgoing messages with a precision timestamp and handle the jitter correction the receiver.

[djacobow]

Short answer: no

Longer answer: if you can live with meeting those jitter requirements most of the time, but with an occasional flub, you can probably take a basic Linux distro and remove almost everything that yes running, add back in just what you need, and see what happens.

Longer still: a Linux kernel with the real-time patch applied does better still but is still not hard real-time. However, I suspect on a modern system you can meet your 10ms jitter requirement.

Provably meets the spec: you're gonna need an rtos.

[Siwastaja]

Even if you could, TCP is not suitable for such low-jitter requirements. You are using wrong tool for the job. MQTT isn't "realtime". Don't use MQTT for microcontroller sensors that need realtime behavior. Handle all realtime stuff on microcontrollers directly, preferably within one microcontroller, or if multi-MCU solution is needed, use something like CAN bus.

[tszaboo]

Just targeted at localhost, you should be able to reach quite a bit of consistency. Is it going to be like your specifications? No idea.
Get a modern system with plenty of free resources, write a 4 line python script and look at the data with Wireshark, you will see.

[ejeffrey]

So there is no way to get a guarantee.  Under normal operation in Linux or Windows the tail latency curve is huge. You can get some pretty big improvements but it's hard to get down to zero.

That said, 10 ms is probably achievable.  Write a C program that makes no unneeded IO calls and see where you are.  The next step is to set a realtime scheduling priority and mlock your memory to prevent swapping.  Note that programs with realtime scheduling can render your system unusable by consuming 100% CPU time and not yielding.

If you need to go down beyond a few milliseconds jitter you have to get into more aggressive system tuning like interrupt shielding and replace sleeps with busy waits.