Ring-buffer allocation

GNU Radio
1

Eric, et al:

How does the ring-buffer allocation work in Gnu Radio?

For example, if I’m shuffling vectors around–let’s say 16000000 complex
items per vector, how many of
these vector-sized “items” are allocated in a ring buffer between a
producer and a consumer?

How much room is there for scaling-back on the sizes of the ring buffers
when the individual items
are really large?

–
Marcus L.
Principal Investigator, Shirleys Bay Radio Astronomy Consortium

2

On Sun, Feb 01, 2009 at 07:56:33PM -0500, Marcus D. Leech wrote:

Eric, et al:

How does the ring-buffer allocation work in Gnu Radio?

For example, if I’m shuffling vectors around–let’s say 16000000 complex
items per vector, how many of
these vector-sized “items” are allocated in a ring buffer between a
producer and a consumer?

2 or 3 unless the guy downstream is a decimator, then we allocate at
least as many as his decimation factor.

How much room is there for scaling-back on the sizes of the ring buffers
when the individual items
are really large?

A couple of printfs added to gr_flat_flowgraph::allocate_buffer will
tell you what’s being allocated. Let me know if you find anything
that looks out of line.

Eric

3

Eric B. wrote:

OK. It may no longer be double buffering, so your throughput may be
down. But, hey, if it’s working :slight_smile:

Eric

OK, so I looked into this further. If I work backwards from the
file-sink back to the USRP, I have
a float vector of 16e6 items, which was costing 250e6, a complex
vector of 16e6 items, which was
costing 500e6, another 16e6 complex vector costing 500e6, and a
complex stream of 32e6 items, costing
250e6 memory.

I added logic to gr_flat_flowgraph::allocate_buffer so that if nitems

= 4 and item_size >= 1<<2, then
nitems /= 2.

That reduced the memory footprint considerably, and still gives you
double buffering between blocks.

–
Marcus L.
Principal Investigator, Shirleys Bay Radio Astronomy Consortium