Re: Which guarantees, if any, do messages provide?
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" > Cc: "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 >
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
Which guarantees, if any, do messages provide?
Hello, I am currently trying to use messages as part of my signal chain and facing some obstacles. 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). Similarly, I create 2 of these custom blocks and sum their output signals. "Message Strobe" sends the same message to both blocks. Ideally the pulses would align perfectly and I would see one pulse. However, I see two pulses having a random delay (probably because the message arrives at different times at the blocks). 1.) What is the typical latency of messages? 2.) Related, what is typically the maximum speed for sending messages? Is sending messages at >1kHz (i.e., "Message Strobe" with interval <1ms) meaningful? 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?) 4.) Can I be sure that all messages are received or does gnuradio silently drop messages under certain conditions? 5.) Are messages always received in correct order? Thanks, Lukas
