discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Long PDUs


From: Martin Braun (CEL)
Subject: Re: [Discuss-gnuradio] Long PDUs
Date: Wed, 17 Apr 2013 17:34:54 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

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

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

Attachment: pgp9krMGHeCNH.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]