[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eric Blossom
Subject: Re: [Discuss-gnuradio] Thread scheduling for high-sensitivity, high-resolutionFFTs
Date: Tue, 6 Jan 2009 21:38:48 -0800
User-agent: Mutt/1.5.18 (2008-05-17)

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


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...]


reply via email to

[Prev in Thread] Current Thread [Next in Thread]