discuss-gnuradio
[Top][All Lists]
Advanced

[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





reply via email to

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