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" <246...@gmail.com> > An: "Lukas Haase" <lukasha...@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 >