Broker Latency

[mongldroid]

Currently running the broker on an esp8266. The idea is to have a plethera of client devices where there is one device on each drum in my kit which is getting readings from a piezo vibration sensor.

The broker and everything seems to be running fine technically speaking however I have noticed when I have even just a short burst of publishes (issues even with three) they broker is seemingly slow to process them.

For example if I play quarter notes there is 0 noticeable latency and the broker recieves the velocity of the drum hit with near real time. Yet if I play a 16th bar. the messages lag into the server over a broader time. (If I hit 5 times in a second, it may take 2 seonds to play all the notes on the broker side, but when hitting one note every second there is 0 latency)

The debounce on the trigger is 80ms so in testing with jsut one client no messages are coming faster than 80ms and there is still almost a second of lag when a series of quick hits comes in.

Is there a way to optimize this. I cannot for the life of me understand why the lag happens considering this is basically a c++ FIFO buffer server similar to class projects I have done. This should be working at microsecond level, let alone 80ms cycle lvl, correct?

The LED on the transmitter is set to flash on each publish and operates perfectly even with rapid drumming. no lag, perfect timing.

I am not using any delays.

Should it lag this much just on 4 messages over 200ms?

esp_broker.txt esp_client.txt

[martin-ger]

Interesting application! Actually, I havn't done any performance measurements right now, but I would also like to understand it...

What happens, if you do just a println("x"); instead of the Midi-call on the broker - same delay?

[mongldroid]

correct, that is actually the primray metric i have used.. watching the serial monitor to compare my hits to look for visual lag. i thought maybe the print may be slowing things down but should be no different than sending the midi cmd

i just cannot understand why latency only happens on burst but works flawless.

On Tue, Feb 26, 2019, 2:11 PM martin-ger notifications@github.com wrote:

Interesting application! Actually, I havn't done any performance measurements right now, but I would also like to understand it...

What happens, if you do just a println("x"); instead of the Midi-call on the broker - same delay?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_martin-2Dger_uMQTTBroker_issues_31-23issuecomment-2D467594435&d=DwMCaQ&c=ODFT-G5SujMiGrKuoJJjVg&r=__X4nP_dyIbKqSfV1PEcNIMj0wVCho0ZbTD6_1BwBKk&m=Pklmv8hDDL2txWcyQABcYoRhVnyvzToV-SfJqPu8yDw&s=kA55AEsN2rdQxAo1JkGR_to3O6HhsatmCMBJe1ujWwI&e=, or mute the thread https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AZiK3y0kkqZt-5F4ubznB-2DfNFuPMip-2DJiDks5vRZTzgaJpZM4bS-5FVo&d=DwMCaQ&c=ODFT-G5SujMiGrKuoJJjVg&r=__X4nP_dyIbKqSfV1PEcNIMj0wVCho0ZbTD6_1BwBKk&m=Pklmv8hDDL2txWcyQABcYoRhVnyvzToV-SfJqPu8yDw&s=bXx5h7y_0xoxsPrDt3QZ0icM8m6axZWgg6hyv_0MCXU&e= .

[martin-ger]

We are talking about TCP here - this means we acks going back. Maybe they are delayed. Could you do the same test using a Mosquitto broker on a Linux/Raspi box? Just to make sure, that the delay really happens on the broker?

[mongldroid]

I can try that. I am quit confident the lag is not in the broker itself because, cmon its a FIFO buffer in c++, it doesn't really get faster or more efficient hardly.

I am wondering if you can think of anything thta might help the lag, which is probably from TCP. Maybe parraelize it a bit with more than one TCP connection or something. Maybe you can suggest an alternate way of sending exactly 4byte packets.

Ive tried UDP but reliability made it a nonsolution (every hit has to make it in music lol), I thought for sure this was the solution. Maybe a simple moded web server would work faster.

Maybe I need to make my "mothership" a raspberry pi with a full mosquito, maybe an esp just wont cut the mustard for what I need, but I cannot imagine why it could not be done.

[RudyFiero]

As far as UDP. Send three times with a small delay between. On the receive end, if the message is the same as the last, then discard. You need a message counter just to identify if it is a duplicate.

Don't even consider multicast or broadcast. Unicast only.

[mongldroid]

The latency is agreeably in TCP as you suggest. I wrote up some better UDP and things move without lag.

So from this, it brings up a question for me. Since MQTT has multilevel quality of service, why not implement qos 0 as udp, it fits the definition pretty nicely and then do TCP handshake for qos >0