Long PDUs

GNU Radio
1

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.

–sean

2

On Wed, Apr 17, 2013 at 10:12:31AM -0400, Sean Nowlan wrote:

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).

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

–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

3

On 04/17/2013 11:34 AM, Martin B. (CEL) wrote:

streaming with precise timing control (using USRP). Many times I’ll
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

4

On Wed, Apr 17, 2013 at 8:34 AM, Martin B. (CEL)
[email protected]wrote:

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.

For robustness, we should probably have a way to retrieve what the “MTU”
is
for a tagged stream block.

5

On 04/17/2013 01:52 PM, Johnathan C. wrote:

For robustness, we should probably have a way to retrieve what the
“MTU” is for a tagged stream block.

Just thinking out loud: could this be worked into the
tagged_stream_block class? If mtu is left as a default, behavior will be
identical to the way it’s defined now and work() will always get called
with the exact number of items a derived block wants. If a length tag
comes along that is greater than the mtu, it should shout its
disapproval and/or truncate the packet and/or “fragment” (though this
introduces even more nightmares… what’s next, fragment offset tags??
actually, maybe…). However if mtu is defined to be bigger than
max_noutput_items/relative_rate, we should handle that case somehow.

6

On Wed, Apr 17, 2013 at 02:09:26PM -0400, Sean Nowlan wrote:

Just thinking out loud: could this be worked into the tagged_stream_block
class? If mtu is left as a default, behavior will be identical to the way it’s
defined now and work() will always get called with the exact number of items a
derived block wants. If a length tag comes along that is greater than the mtu,
it should shout its disapproval and/or truncate the packet and/or “fragment”
(though this introduces even more nightmares… what’s next, fragment offset
tags?? actually, maybe…). However if mtu is defined to be bigger than
max_noutput_items/relative_rate, we should handle that case somehow.

Yep, it should go into gr_tagged_stream_block. Although as you say, it’s
a tricky call what happens in this case.

But in the very least, it should be checked and fail–currently it would
check and run indefinitely.

M

–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association