|
On 04/17/2013 11:34 AM, Martin Braun
(CEL) wrote:
On Wed, Apr 17, 2013 at 10:12:31AM -0400, Sean Nowlan wrote:
I want to see whether "very long" PDUs would break the new tagged
stream model implementation in recent GR versions. Let's say I want
to use tagged streams with length tags to transmit streams that
would require many more samples than a single call to work() could
handle. From diving into the source code, streamed tag blocks look
like they explicitly ask the scheduler for the exact number of
samples needed to process an entire PDU. So it looks like I'll get
into trouble here. I can see how this methodology is smart for many
packet-based protocols, but I basically want to control gated
streaming with precise timing control (using USRP). Many times I'll
need to stream for seconds or minutes, which implies multiple calls
to work() to generate samples.
Hi Sean,
thanks for trying the tagged stream blocks, they are still new and
probably have some unexposed bugs.
The actual derivation from gr_tagged_stream_block works on the paradigm
that the processing is done frame-wise. This has signal processing
advantages (e.g. if you're equalizing a frame with a 2D-equalizer, this
is how you'd like your data to be available), and it also does not
require the blocks to save state (i.e., where in the frame we are).
So yes, you're right: Massive PDUs will cause them to break.
However, this only a convenience. If you have special requirements, you
can always use gr_blocks as before. Then, you must save state, but you
don't have to wait for all the samples to be available before the block
is called in the first place (because that's what
gr_tagged_stream_block's are there for).
So are you then bounded by max_noutput_items inherited from
top_block (or set explicitly)? I didn't see any bounds checking on
length tags to prevent "massive" PDUs in gr_tagged_stream_block.
Also I see PDU length tags as solving another problem - letting
intermediate blocks and sinks know how many items they will have to
process in a row. As we've already discussed, packet-based flows are
a good example. Another is the case I mentioned (though, yes, I can
introduce a length tag to something that inherits gr_block). Another
might be making a PPS signal with a large duty cycle, though there
may be easier ways to do that. Finally, letting UHD know what to do
with PDU length tags even when a burst is expected to be larger than
one buffer passed one work() call.
I can see you're tracking this last one already. :c)
http://gnuradio.org/redmine/issues/530
As you also point out, they work well for packetized data transmission.
When I was working on the new OFDM blocks, I had packets in mind on the
same order as 802.11a packets, so buffer size was never a problem.
MB
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
|