Weired GNURADIO Performance


Today was a day-mare for me. I had to reformat/install gnuradio on my
PC 3
times in few hours.

The story begins when I tried to upgrade my nice working Ubuntu 8.10 OS
the new 9.04 on my old 3.0GHz C2D system (2G RAM). I had an application
which needs much CPU performance. The application is doing a streaming
point FFT with 25MSps on USRP2. The application was consuming about 50%
my CPU (both). That was with Ubuntu 8.10 32 bit + python 2.5 + original
USRP2 firmware ( I think 9936) + gnuradio 10368.

When 9.04 came, I wanted to upgrade my system and even I came with an
to use the 64 bit version with my C2D system. So I reformatted/installed
Ubuntu 9.04 64 bit + python 2.6 + installed latest USRP2 firmware
(10766) +
gnuradio 10945. Every thing was OK.

The surprise was when I started my same application, but its now
about 90% from my CPU!!!. I shocked. I couldn’t figure out what was the
problem because I changed many variables at a time.

To debug the problem, I reformatted/installed Ubuntu 9.04 32 bit +
2.6 + same USRP2 firmware (10766) + gnuradio 10945. This time the CPU
utilization was 75%. So may be this is a bad OS + GNURadio interaction.

To be sure, I reformatted/installed back the Ubuntu 8.10 32 bit + python

  • USRP2 firmware (10766) + gnuradio 10945. When checked with the same
    application, my CPU utilization was back to 50% and I’m very happy now.

I thought sharing it may be useful to gnuradio developers.

Any suggestions/speculations ???

Best Regards,


View this message in context:
Sent from the GnuRadio mailing list archive at

On Sat, May 2, 2009 at 10:15 AM, Firas A. [email protected]

my CPU (both). That was with Ubuntu 8.10 32 bit + python 2.5 + original

Any suggestions/speculations ???
I can speculate: some versions of Ubuntu (i.e. all the ones I’ve
actually looked at) seem to build fftw without SSE/SSE2. I’m using
a copy that I built myself. (This is 64-bit. I don’t know whether
the 32-bit versions have the same problem. I’m also running on Ubuntu
8.10, which does not explain what you’re seeing.)

You could try rebuilding FFTW from source to see if it has any effect.

I’ve attached a little test program that demonstrates the difference

Build like this:
$ g++ -lfftw3 -lrt -O2 -o fftw_bench

Test like this. Adjust as appropriate for your system. 1024 is the FFT
$ ./fftw_bench 1024 # This uses my custom FFTW in /usr/local/lib
Done planning
Took 943574ns, which is 1.08524e+08 samples per second
1753.33 MFLOPS
11.5938 adds 3.5625 muls 1 fmas
5426.18MFLOPS (canonical)
(dftw-direct-32/124 “t2fv_32”)
(dft-direct-32-x32 “n2fv_32”))

$ LD_LIBRARY_PATH=/usr/lib ./fftw_bench 1024 # This uses Ubuntu’s copy
Done planning
Took 1493072ns, which is 6.85834e+07 samples per second
2074.65 MFLOPS
21.125 adds 5.125 muls 4 fmas
3429.17MFLOPS (canonical)
(dftw-direct-16/30 “t1_16”)
(dft-direct-64-x16 “n1_64”))

Some day I’ll get around to filing a bug report with Ubuntu/Debian (I
should figure out whos bug it is first).


This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs