> 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?




Reply via email to