On Tue, Jul 5, 2011 at 6:13 PM, Marcus D. Leech
<address@hidden> wrote:
Relatively simple flow-graph, not complete yet by any stretch of the imagination.
It starts out innocuous enough, but really gets going after a while. The RSS grows by about 150M/minute, the Virtual Size at a somewhat
slower pace. After a few minutes of running, its RSS has grown enough that it's consuming *most* of the physical memory on the system,
and the kernel is starting to look for solutions to the problem, the virtual size grows to about 6.2Gbyte on my system before things get
utterly unusable, and I have to go to the console and kill it off. If I reduce the bandwidth, it grows more slowly, but it still grows, and grows,
and grows, and grows.
I was even well-behaved in my FFT size--4096 bins, which is a nice even multiple of the page-size and everything.
The Gnu Radio memory behaviour is really starting to bug me. A lot. So much so that I'm contemplating going directly from UHD to my
application (in this case, a multi-channel riometer). I really don't want to do that. If I had the time to dedicate to it, and the required depth
of knowledge of the scheduler guts, I'd fix it myself, and post patches. I understand that the memory tricks are stream-performance
"optimizations", but it's rather unoptimal when your system is eaten alive by stuff that, at least given a superficial glance, should be
fairly innocuous (except, perhaps for the 25Msps bit, which nobody would argue is "casual" by any measure).
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
What are you using the vector sink for, I can't find anything that unloads it? If you look at the source code, this block continuously calls "push_back" on a STL vector container (element size is the GNURadio vector). So if nothing ever empties it, then it should consume all the memory space....?