Recommended PC Hardware for Performance


#1

This may be a somewhat banal question, but what would be the optimal
hardware/software configuration needed to leverage the power of
gnuradio?

Core i7 versus Core2 Duo versus Other (maybe cell)?
64-bit Linux versus 32?
Any hardware acceleration/DSP cards?
Amount/type of RAM?

While running some flow graphs on an older machine, I found that I had
designed one of my low pass filters too tightly. The large number of
taps in the FIR consumed all the processing power available, and
starved the USRP for data.

Is there a way to notify the user when a flow graph begins to fail or
fails intermittently?

Thanks!
Tom


#2

On Tue, May 19, 2009 at 08:26:18AM -0400, Tom Lutz wrote:

This may be a somewhat banal question, but what would be the optimal
hardware/software configuration needed to leverage the power of
gnuradio?

Core i7 versus Core2 Duo versus Other (maybe cell)?

Core i7 should have higher memory bandwidth.

64-bit Linux versus 32?

64-bit.

Any hardware acceleration/DSP cards?

No.

Amount/type of RAM?

2GB+

While running some flow graphs on an older machine, I found that I had
designed one of my low pass filters too tightly. The large number of
taps in the FIR consumed all the processing power available, and
starved the USRP for data.

If you’re not using gr.fft_fir_filter_*, you may want to try it.

Is there a way to notify the user when a flow graph begins to fail or
fails intermittently?

You could periodically check the value of u.noverruns()

Eric


#3

Awesome! Thanks for the info. I don’t think I’m using the fft
filters, so I’ll give that a shot.

Tom


#4

On Tue, 2009-05-19 at 08:26 -0400, Tom Lutz wrote:

This may be a somewhat banal question, but what would be the optimal
hardware/software configuration needed to leverage the power of
gnuradio?

Core i7 versus Core2 Duo versus Other (maybe cell)?
gnuradio depends heavily on floating point performance and memory
bandwidth.
It makes good use of multiple cores.

So if you can afford it use a quad-core processor with a high memory
bandwidth.
( i7 quad or a quad core AMD phenom II )

64-bit Linux versus 32?
Definitively 64 bit.
I haven’t measured it recently but I have seen people report that going
from 32 to 64 bit linux gave a very significant performance boost with
gnuradio.
Any hardware acceleration/DSP cards?
Work is being done on a Cell and a GPGPU port (run processing on
videocard) of gnuradio.
I myself am working on the gpgpu port.
At the moment this is done using CUDA which is a nvidia-only technology.

As soon as OpenCL is available this will be rewritten in OpenCL.
OpenCL is a cross-platform technology for doing massive parallel
calculations on different hardware on different OSes (Windows, Linux,
MacosX).
Nvidia has a beta version for Nvidia cards for linux, windows.
ATI is working on a version for their cards.
There will be a IBM Cell version.
The next release of MacosX will have support for it (And will also make
use of it within the OS)

When running on the videocard the memory bandwidth of the videocard is
the main performance differentiator between cards.
(The biggest bottleneck is the transfer of the data over the PCI-express
bus and the call-overhead but this is about the same for all PCI-express
videocards)

Don’t expect the GPGPU port to be production ready within the next year
or two though. So unless you want to want to help with this port you
don’t have to be picky which videocard to choose.
If you do want to help with the GPGPU port I would suggest a nvidia GTX
200 series card for best performance (Nvidia GTX 285 if you can affort
the financial and power budget)

I myself use a nvidia 9600 GT which is not that fast, but gives a good
impression if rewriting gnuradio for running on the GPU will give a
speed improvement on average machines.

Amount/type of RAM?
Fast, faster fastest. Amount is not that critical.
2 GB or more should do for most Gnuradio work on Linux.

While running some flow graphs on an older machine, I found that I had
designed one of my low pass filters too tightly. The large number of
taps in the FIR consumed all the processing power available, and
starved the USRP for data.
This is exactly why I started the GPGPU port.

You can sometimes have better results when you use the gr_fft filter in
stead of the gr_fir filter.
It depends on your decimation factor if this has better or worse
performance.
low decimation factor: use FFT
high decimation factor: use FIR

If in doubt: benchmark

Is there a way to notify the user when a flow graph begins to fail or
fails intermittently?

I don’t know any.
Anybody else knows a trick for this?

Greetings,
Martin


#5

Martin DvH wrote:

I’m currently using a QX9770 overclocked to 3.6GHz, but with somewhat
sluggish (for that processor) memory.
I’m hoping to get a memory upgrade soon.

I run large FFTs for SETI analysis, and that requires lots of memory,
and increasing certain system parameters
(SHMMAX).

The “Next Generation” of my standard hardware platform will be a Core i7
920, overclocked as much as reasonable,
with fast memory (6GB to 12GB).

I’m doing multi radio astronomy and SETI analyses in parallel on data
streams that may be arriving as fast as
16M samples per second. More CPU Igor, more CPU!

Can’t wait until Intel starts pushing hard on the new bus (QPI??), and
brings out processors with more than 4 CPUs.


Marcus L.
Principal Investigator, Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org