[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: |
Marcus D. Leech |
Subject: |
Re: [Discuss-gnuradio] Thread scheduling for high-sensitivity, high-resolutionFFTs |
Date: |
Wed, 07 Jan 2009 01:04:31 -0500 |
User-agent: |
Thunderbird 2.0.0.18 (X11/20081119) |
Eric Blossom wrote:
> 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
>
>
Yes, I came to the same conclusion about gr.interleave trickery myself,
and will have to noodle over it when I'm awake.
--
Marcus Leech
Principal Investigator, Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
- [Discuss-gnuradio] Thread scheduling for high-sensitivity, high-resolution FFTs, Marcus D. Leech, 2009/01/06
- Re: [Discuss-gnuradio] Thread scheduling for high-sensitivity, high-resolution FFTs, Eric Blossom, 2009/01/06
- Re: [Discuss-gnuradio] Thread scheduling for high-sensitivity, high-resolutionFFTs, Marcus D. Leech, 2009/01/06
- Re: [Discuss-gnuradio] Thread scheduling for high-sensitivity, high-resolutionFFTs, Eric Blossom, 2009/01/07
- Re: [Discuss-gnuradio] Thread scheduling for high-sensitivity, high-resolutionFFTs,
Marcus D. Leech <=
- RE: [Discuss-gnuradio] Thread scheduling for high-sensitivity, high-resolutionFFTs, Bob McGwier, 2009/01/07
- Re: [Discuss-gnuradio] Thread scheduling for high-sensitivity, high-resolutionFFTs, Marcus D. Leech, 2009/01/07
- RE: [Discuss-gnuradio] Thread scheduling for high-sensitivity, high-resolutionFFTs, Bob McGwier, 2009/01/07
- [Discuss-gnuradio] Object model for stdgui2, Paul Mathews, 2009/01/14
Message not available