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?
> Gesendet: Freitag, 22. Mai 2020 um 03:45 Uhr
> Von: "Sylvain Munaut" <246...@gmail.com>
> An: "Lukas Haase"
> Cc: "firstname.lastname@example.org"
> Betreff: Re: Which guarantees, if any, do messages provide?
> > 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?