Re: [Discuss-gnuradio] usrp2_fft.grc hangs when executed

[Marcus D. Leech]

On 05/15/2011 07:11 PM, Elvis Dowson wrote:
> Reducing the refresh rate to 5fps makes it a bit more responsive. A value of 
> 10 makes it un-responsive. My sample rate is 3.125M sps using a USRP2, using 
> the UHD drivers.
>   
usrp2_fft.py was written for "classic" -- did you modify it for UHD? 
Also, you reported a decimation
  of 16, which gives 6.25Msps with USRP2.

Also, turn on averaging--that seems to help the performance, whose main
issue seems to be inside
  the rendering code in OpenGL and the Python "goo" that drives the FFT
display in Gnu Radio.

One of the advantages of the QT graphical sinks is that most of the
computational dancing around
  that is required to "set up" the FFT display is done in C++ code,
rather than Python.  But I find
  the Qt sinks to be very "pre-production".  I don't like the user
interface very much, and they're
  currently too monolithic and inflexible.



>   
>> What type of system are you running on?  What CPU, what speed?  Multi-core 
>> or single-core?
>>     
> I just resurrected my old ThinkPad T42p, which is a 1.8GHz Pentium-M centrino 
> processor, 2GB RAM, ATI FireGL T2 128MB graphics, gigabit ethernet and a 
> 160GB hard drive, running Ubuntu 11.04 32-bit.
>   
That's not exactly a really speedy CPU.  Might be adequate for
experimenting at low bandwidths
  (1Msps or maybe 2Msps), but it's rather long in the tooth.

I have a T60 that I use sometimes, but only at 1 or 2Msps.


> Running gnuradio virtualized on my iMac quad-core had issues with audio with 
> older releases of gnuradio. I'll need to check with the recent release 
> though, if the audio issue still persists using vmware.
>
> I have to say, this old T42p running Ubuntu or Windows XP, is as responsive 
> as any of today's multi-core i5 or i7 processors for simple daily tasks (web, 
> downloads, etc) and bootup and shutdown times. The only areas it doesn't cut 
> is for computationally intensive tasks. e.g. handling large datasets, 
> generating a 8192 bit ssh rsa key (took more than 10 mins compared to a few 
> seconds on an i7), program compilation times, etc.
>
>
>   
Well, signal processing is definitely in the "computationally intensive"
zone :-)

-- 
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org