Forum: GNU Radio Memory oinking

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.
Marcus D. Leech (Guest)
on 2009-01-29 17:49
(Received via mailing list)
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
http://www.sbrac.org
Eric B. (Guest)
on 2009-01-29 21:04
(Received via mailing list)
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
Marcus D. Leech (Guest)
on 2009-01-29 21:10
(Received via mailing list)
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
http://www.sbrac.org
This topic is locked and can not be replied to.