discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] A simple flow-graph that is giving me infinite gr


From: Johnathan Corgan
Subject: Re: [Discuss-gnuradio] A simple flow-graph that is giving me infinite grief
Date: Wed, 29 Jun 2011 13:51:49 -0700

On Wed, Jun 29, 2011 at 09:24, Marcus D. Leech <address@hidden> wrote:
On 29/06/2011 12:12 PM, Johnathan Corgan wrote:
GNU Radio achieves its streaming performance in part due to a circular buffer design that maps the same physical memory twice in the virtual memory map for the process, directly adjacent to each other.  This allows work function code to avoid doing any bounds checking or modular index arithmetic operations when reading and writing its input and output buffers.  Going "off the end" of the buffer just results in accessing the start of the buffer which is mapped into the next block of memory.  Not only does this make the code and I/O much faster, but the work function code gets a lot simpler.
I wonder if that assertion is generally true, or only in some cases?  Increment and test shouldn't be *that* expensive.

I'm sure the benefit varies depending on the situation, including some where there is no benefit.  But modulo increments add a conditional operation for every pointer increment, which can cause a processor pipeline stall, and takes up register file space to hold the array boundaries for every input and output stream.  It also forces the author of the work() function to know about how GNU Radio handles circular buffers.  The double-mapped circular buffer lets the work() function treat all its inputs and outputs as linear arrays in memory, no matter the actual case.
 
 My recollection is that sizes get ballooned outwards based on the degree of decimation downstream from the source block, which is
  a policy I've never quite gotten my head around.  The FFT in my flow-graph might get decimated by a factor of 10 or more, which given
  the policy I mentioned, might lead to chunky allocations.

Ah, I think I remember this discussion a while back.  It's the gr.keep_one_in_n block used to decimate the sample stream into blocks that update the FFT sink at the requested screen update rate.  Decimator blocks tell the runtime their decimation ratio via set_relative_rate().  Knowing this, GNU Radio expands the buffer allocation by twice the decimation rate, to allow enough room for the upstream block thread to be simultaneously writing a full set of inputs and the downstream block thread to be reading a full set of inputs:

http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/master/annotate/gnuradio-core/src/lib/runtime/gr_flat_flowgraph.cc#L106

Since gr.keep_one_in_n is simply discarding n-1 input items, and doesn't need to actually process them like most decimators would, there may be an alternative way to handle this for this particular block.

Johnathan

reply via email to

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