Forum: GNU Radio Ring-buffer allocation

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus D. Leech (Guest)
on 2009-02-02 01:57
(Received via mailing list)
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 Leech
Principal Investigator, Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2009-02-03 03:29
(Received via mailing list)
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
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus D. Leech (Guest)
on 2009-02-04 15:57
(Received via mailing list)
Eric Blossom 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 Leech
Principal Investigator, Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
This topic is locked and can not be replied to.