Forum: GNU Radio Big-arsed FFTs in Gnu Radio

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus D. Leech (Guest)
on 2009-01-26 21:46
(Received via mailing list)
Well, after some amount of experimentation with sysctl settings, I've
been able to construct a single-thread FFT
  that has an input bandwidth of 8Msps, and an FFT size of 8M points!!!

This is much better than I was hoping for, and it will allow me to build
a SETI analyser with 1Hz resolution.

I had to balloon out kernel.shmmax to 512MB to support this application.

This thing is a monster, though.   The virtual size of the process is
over 4G, and the resident set size is about 2.3G!!

It consumes about 30% of my Quad-core Q6600 system that is overclocked
to 3.5GHz.  The CPU consumption was less
  than I was expecting, but these Core-2 CPUs have awesome
floating-point performance (about 7GFLOP/core) at standard
  clock speeds, and even better when overclocked.

My estimate of the number of FLOPs required per FFT at this size is
about 1-2GFLOPs.

So, now I'm trying to decide how to code the analyser.  My previous
analyser was done in Python, using
  spectral estimates stored in an FFT probe buffer.  But at 8M points,
I'll need to code the analysis phase
  in C/C++.  So, do I make a "SETI Analyser" block, or use a named-pipe
and feed an external analysis process?
  I did a FIFO-based program for purposes of testing last night, which
simply takes the raw FFT outputs, and
  runs them through a single-pole IIR filter, and then reduces the
number of bins for display using Gnu Plot.
  That works just fine.

Marcus Leech
Principal Investigator, Shirleys Bay Radio Astronomy Consortium
This topic is locked and can not be replied to.