Memory oinking

GNU Radio
1

I have a simple flow-graph,

A USRP, single channel, and a large FFT block, followed by a “vector to
stream”, and a file-output block.

The FFT is 8M points, which for complex float samples, give something
like a 64M memory footprint.

But I’m finding that the virtual size of the resulting process is
4.5GB!, with an RSS of about 2.3G.

This seems larger than you’d expect, by a fairly large factor!

For comparison, I have a C program that processes the samples created by
the Gnu Radio “front end”,
which has:

  120 8M buffers (unsigned char)
  2 x 8M buffers (float)

The virtual size of this process is only about 1G, with a similar RSS
(it touches those buffers very
regularly!).

It seems to me that there only needs to be perhaps a couple of buffers
per block inside Gnu Radio,
which at worst gives you something like 8 complex buffers (about 64M
per buffer for complex float)
in my flow-graph. Why the massive hugeness in memory footprint?

Now, I’ll agree that memory is cheap these days, but scaling my
application is going to be limited
by what Gnu Radio is capable of, rather than my back-end C program.

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

2

On Thu, Jan 29, 2009 at 10:33:06AM -0500, Marcus D. Leech wrote:

I have a simple flow-graph,

A USRP, single channel, and a large FFT block, followed by a “vector to
stream”, and a file-output block.

The FFT is 8M points, which for complex float samples, give something
like a 64M memory footprint.

Sounds right.

In the naive interface to FFTW we’re using, I’m allocating
additional input and output buffers for another 128M. I think I can
get rid of that.

But I’m finding that the virtual size of the resulting process is
4.5GB!, with an RSS of about 2.3G.

That’s big!

(it touches those buffers very
regularly!).

It seems to me that there only needs to be perhaps a couple of buffers
per block inside Gnu Radio,
which at worst gives you something like 8 complex buffers (about 64M
per buffer for complex float)
in my flow-graph. Why the massive hugeness in memory footprint?

Not sure. Can you post a link to the code (or the code if it’s small)
and I’ll take a look at it.

Now, I’ll agree that memory is cheap these days, but scaling my
application is going to be limited
by what Gnu Radio is capable of, rather than my back-end C program.

Eric

3

Eric B. wrote:

Not sure. Can you post a link to the code (or the code if it’s small)
and I’ll take a look at it.

http://www.sbrac.org/files/multi_fft_graph.py
http://www.sbrac.org/files/multi_fft.grc

I have enough CPU headroom that I could easily double the size of the
FFT, but the memory
footprint will be a big issue!

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