RE: [Discuss-gnuradio] Thread scheduling for high-sensitivity, high-resolutionFFTs

[Bob McGwier]

>From what Eric has described (which should work), you have choices.  The
choices would be to increase sensitivity by adding the results of the fft's
which is the same as producing spectra from long term autocorrelation which
will increase sensitivity O(n) because it is coherent averaging or if you
sist on noncoherent averaging sensitivity will be increase O(sqrt(n)) but
only by decreasing the variance of the noise.  And/or you can build larger
fft's from the intermediate ones via several techniques to increase
frequency resolution.  The latter requires more careful organization because
you do not wish to window the smaller ones if you wish to combine them
later.  This would require windowing in the frequency domain and necessarily
the expense of convolution rather than multiplication.

This is all a fruitful area for experimentation now that we have the new TPB
scheduler.

Bob


ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"And yes I said, yes I will Yes", Molly Bloom


-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of
Eric Blossom
Sent: Wednesday, January 07, 2009 12:39 AM
To: Marcus D. Leech
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] Thread scheduling for high-sensitivity,
high-resolutionFFTs

On Tue, Jan 06, 2009 at 11:20:48PM -0500, Marcus D. Leech wrote:
> Eric Blossom wrote:
> >
> >
> > Is this an SMP machine, or a cluster?
> >
> > If SMP, it'll "just work".  If it's a cluster, you'll need to figure
> > out how to partition separate instantiations of GR on each node.
> >
> > Eric
>
> SMP.
> 
> Describe how it'll "just work"??
> 
> Maybe I haven't looked at all the blocks carefully enough, but I can't
> immediately see how to do this.
> 
> I basically want a "distributor" block that distributes FFT input frames
> to multiple instances of an FFT computation,
>   across multiple threads, and have the results of the separate FFTs
> synchronized.

Sounds good.  Sorry,  I misunderstood your goal.
(I'm working on the guts of FFTW now and have FFT on the brain...)

I think we have the blocks you need to do the fanout and fanin
already.  They're disguised as

  gr.deinterleave(itemsize)
  gr.interleave(itemsize)

I think you could use them like this:

  fft_size = 512

  usrp = ...

  fanout = gr.deinterleave(fft_size * gr.sizeof_complex)
  fanin = gr.interleave(fft_size * gr.sizeof_complex)

  fft0 = ...
  fft1 = ...
  fft2 = ...
  fft3 = ...

  connect(usrp, fanout)

  connect((fanout, 0), fft0)
  connect((fanout, 1), fft1)
  connect((fanout, 2), fft2)
  connect((fanout, 3), fft3)

  connect(fft0, (fanin, 0))
  connect(fft1, (fanin, 1))
  connect(fft2, (fanin, 2))
  connect(fft3, (fanin, 3))


Each block runs in its own thread, so this should run faster on an SMP
machine.  Please let us know if this works for you!

[FYI, there are also two extra copies happening in the gr.fft_* block that I
now know how to remove...]

Eric


_______________________________________________
Discuss-gnuradio mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio