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

[Eric Blossom]

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