Re: Which guarantees, if any, do messages provide?

[Lukas Haase]

Hi Sylvain,

That was very useful, thanks.

I did some more experiments meanwhile and they seem to confirm what you are 
saying: Messages come in at pretty much random times and in big bursts (despite 
in order). For example, the messages of "Message Strobe" every 100ms (which is 
a very long interval) arrive in bursts of three every 300ms. So I think these 
messages are pretty much useless except for simple, nontime critical things.

I ended up building a "Message-to-Tag" block. It queues incoming messages and 
inserts them as tags at predictable intervals.

That works well. However, now I have a stream of zeros (the block doesn't 
output any data except tags) with a tag attached to a zero once every tens of 
thousands of samples. Feels pretty wasteful. Is there really no better way?

Thanks,
Lukas


> Gesendet: Freitag, 22. Mai 2020 um 03:45 Uhr
> Von: "Sylvain Munaut" <246tnt@gmail.com>
> An: "Lukas Haase" <lukashaase@gmx.at>
> Cc: "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org>
> Betreff: Re: Which guarantees, if any, do messages provide?
>
> Hi,
>
> > For example, I use "Message Strobe" to create a message every 10ms. A 
> > custom blocks creates a pulse when the message is received (it does so by 
> > putting the message into a std::queue in the message handler and retrieving 
> > it in the work function).
> > When I trigger on one pulse and zoom out, I ideally would see one pulse 
> > exactly every 100ms. However, the pulses jump around (i.e., the period 
> > always changes).
>
> Yeah, that's why they're called asynchronous messages.
>
>
> > 1.) What is the typical latency of messages?
>
> Too dependent on too many factors to provide any meaningful answer.
> They're not artificially delayed ... so "as fast as possible" is the
> only thing I can say.
>
>
> > 2.) Related, what is typically the maximum speed for sending messages? Is 
> > sending messages at >1kHz (i.e., "Message Strobe" with interval <1ms) 
> > meaningful?
>
> As fast as you can process them.
> I've had bursts decoder use message for decoded bursts and that was
> for sure reaching 1k packet per second.
>
> I thought there was a back pressure mechanism to block senders if the
> queue was too long, but I can't find it in the code :/  So if there
> really isn't any, be careful of your memory footprint could grow
> without bounds.
>
>
> > 3.) Are there any "guarantees" on maximum/minimum delay? (for example, I 
> > read that the message handler is guaranteed to be executed when work() is 
> > not. Is an upper bound of delay (in samples) given by the worst case 
> > execution of the work function, i.e. the size of the output buffer?)
>
> None whatsoever.
>
>
> > 4.) Can I be sure that all messages are received or does gnuradio silently 
> > drop messages under certain conditions?
>
> It won't drop messages.
>
>
> > 5.) Are messages always received in correct order?
>
> Yes
>
>
> Cheers,
>
>      Sylvain
>