# Ring-buffer allocation

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

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

Eric B. wrote:

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

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