Hi Jeon, As soon as you have packetized data, yes, I agree, messages will usually be easier to deal with. To apply the concept of limited bursts to sample streams, there's the "tagged stream block" paradigm, which you could understand as the zombie love-child of streams, stream tags and the concept of passing messages.
but: much of SDR revolves around handling handling digital signals in ways that don't know or care about things such as packets – for example, take an equalizer: Sure, whatever *estimates* the way the channel is distorted needs to understand what a packet looks like to be able to find pilot tones, preambles etc, but the equalizer might simply be a FIR filter applied to the received signal – and thus, doesn't care at all about where packets end or start. Furthermore, even within packets, there are a lot of cases for which considering the contents of the packets as "stream" is easy/comfortable – for example, if you apply the same operation on all items in a packet, just pushing the content of that packet through something that applies things to a stream of items is really easy, and efficient. > Though I am not sure if it is correct, but I can guess reasons: > maximum length limitation of message, ah, well, that would be something one could fix. Also, I'm not aware of any maximum length for messages > scheduler, memory and handling overhead, Indeed, messages might need to be copied – whereas sample streams actually never get copied from an output to an input port; the "stream connection" in between is actually a single, circular buffer with a single writer (at the upstream block's output), and 1 to N readers (on the downstream block(s) input(s)), which limit the speed at which the upstream block can produce data. This back-pressure is the mechanism by which GNU Radio regulates the flow of data – if your flowgraph consisted of message passing alone, every block would just constantly spit out messages at maximum speed, at which time the consuming blocks at some point will experience a buffer filling, and would simply need to drop messages. There's no "back-channel" for blocks to tell their upstream neighbors "hey, slow down, I can't deal with this as fast as you're producing it" with messages. Also note that computational performance often hinges on doing as much of the same operation "at once" as possible – which is why the circular buffer concept mentioned above allows for very good CPU cache utilization. > compatibility with the built-in and existing blocks. Very important point; that's why the tagged stream blocks mentioned above are relevant: they work with the standard blocks such as multiply_const without any further ado. Best regards, Marcus On 06.07.2016 13:03, Jeon wrote: > Primer: http://gnuradio.org/doc/doxygen/page_msg_passing.html > > Though GNU Radio is 'stream' based, lots of communication systems have > well-defined concepts of packet and frame. > > For those cases, it is sometimes useful to use message passing rather > than stream. Say, publishing and subscribing a message seems easier > and more convenient than passing a stream with a tag 'packet_length' > and building a state machine. > > But then one question comes up. 'Why is stream used more frequently > and widely than message passing?' Though I am not sure if it is > correct, but I can guess reasons: maximum length limitation of > message, scheduler, memory and handling overhead, compatibility with > the built-in and existing blocks. > > A link for primer doesn't tell some pros and cons about stream and > message. I wonder how far I can use message passing. To tell straight, > I can build all my own OOT blocks using message passing and unpack it > into stream to feed to USRP sink. But I think there are some reasons > for not doing this. > > Regards, > Jeon. > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
