gnuradio performance problems

[Ton Machielsen]

Is a Dual core Athlon with 3Gb memory running 32 bit Ubuntu 12094 LTS sufficient to run gnu-radio?

I am following the tutorial here: http://www.csun.edu/~skatz/katzpage/sdr_project/sdr/grc_tutorial1.pdf and on the first page when i run a couple of graphica sinks simultaneously the sink windows turn dark and stop.

At that point both cores are running at appx. 50%

Is this a performance problem of the PC or is there something wrong with gnu-radio?

Thanks,

Ton.

[Adam Nielsen]

> Is a Dual core Athlon with 3Gb memory running 32 bit Ubuntu 12094 LTS
> sufficient to run gnu-radio?

Hard to say without knowing how fast the CPU is :-)

> I am following the tutorial here:
> http://www.csun.edu/~skatz/katzpage/sdr_project/sdr/grc_tutorial1.pdf and on
> the first page when i run a couple of graphica sinks simultaneously the sink
> windows turn dark and stop.

I am running a quad core @ 2.4GHz and I have trouble running two graphical
sinks at the same type - I can just manage it but it can be very laggy trying
to interact with. Having said that, switching one off doesn't really make a
difference, so I think it's more related to the rest of the processing in the
flow graph than the graphical elements themselves.

> Is this a performance problem of the PC or is there something wrong with
> gnu-radio?

I think the performance is very sensitive to how you arrange the flow graph.
Perhaps you can optimise it some more if the graphical sinks aren't performing
so well. Maybe there's a filter or something you could remove if you don't
need it for some test?

Cheers,
Adam.

[Miguel A. Vallejo]

No matter how big, fast or new is your computer.

No matter how many cores, RAM or graphics it has.

It will be small to move GNURadio properly.

Sad but true.

[Ton Machielsen]

Do i smell an architecture complaint here?

--
You received this message because you are subscribed to the Google Groups "Ultra Cheap SDR" group.
To post to this group, send email to ultra-cheap-sdr@googlegroups.com.
To unsubscribe from this group, send email to ultra-cheap-sdr+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ultra-cheap-sdr?hl=en.

[imo]

FYI- I can run the 4channel NBFM example (posted in this forum) with an old amd64 dual core @ 2.2GHz 2GB ram with 85% cpu utilisation at both cores under ubuntu 10something. i.

[Miguel A. Vallejo]

Ton Machielsen wrote:

>>> Do i smell an architecture complaint here?

Maybe... ;-)

In my small experience with GNU Radio has been always a big cpu eater, even for the simplest flowgraphs. I wonder how someone can make complex flowgraphs (like DVB-T transmitter / receiver or GSM base station) without a supercomputer ( http://en.wikipedia.org/wiki/Supercomputer ) Maybe phyton is not the best choice for such application... I don't know.

Anyway, it is what we have, it is free and is powerful, so I suspect I can't complaint!

[Adam Nielsen]

> *>>> Do i smell an architecture complaint here? *
>
> Maybe... ;-)

The only problem with the architecture is that it's all done in software
:-) Software is slow, which is why until now it's always been done in
hardware. If the performance was good today, then SDR would have been
popular already for many years.

> In my small experience with GNU Radio has been always a big cpu eater,
> even for the simplest flowgraphs. I wonder how someone can make complex
> flowgraphs (like DVB-T transmitter / receiver or GSM base station)
> without a supercomputer ( http://en.wikipedia.org/wiki/Supercomputer )
> Maybe phyton is not the best choice for such application... I don't know.

According to the docs, Python is only used to join the blocks together,
all the actual processing is done in C using high performance libraries,
which optimise code for your specific CPU (which could explain why
people complaining about poor performance all seem to be running AMD
CPUs...maybe they're not well optimised yet.)

> Anyway, it is what we have, it is free and is powerful, so I suspect I
> can't complaint!

I think the problem is the target audience. GNU Radio is aimed at
people doing research with RF. It's designed to be flexible and
accurate first, and speed comes second. I don't think anyone would
normally build a DVB-T transmitter/receiver in GNU Radio, but people
using it professionally might build small components of a DVB-T device
to test hardware they are designing.

Contrast that with a program like HDSDR which is not as flexible, but is
a lot faster because it is aimed at a different group of people -
hobbyists rather than researchers.

Cheers,
Adam.

[Ton Machielsen]

On Thu, May 10, 2012 at 4:30 AM, Adam Nielsen <a.ni...@shikadi.net> wrote:

I think the problem is the target audience.  GNU Radio is aimed at people doing research with RF.  It's designed to be flexible and accurate first, and speed comes second.  I don't think anyone would normally build a DVB-T transmitter/receiver in GNU Radio, but people using it professionally might build small components of a DVB-T device to test hardware they are designing.

I agree with what you are saying, but if a VERY BASIC flow makes gnuradio grind to a halt also researchers cannot find many uses of it. I agree that my PC is not the most powerful in the world, but come on, the flow is VERY VERY basic....

Anyway, IIWII (it is what it is).

Ton.

[Adam Nielsen]

> I agree with what you are saying, but if a VERY BASIC flow makes gnuradio
> grind to a halt also researchers cannot find many uses of it. I agree that my
> PC is not the most powerful in the world, but come on, the flow is VERY VERY
> basic....

Up until now, any researcher would've had to purchase a USRP or similar.
Given the price of those, a top of the line computer wouldn't be a problem :-)

However if a basic flow graph is making your PC grind to a halt, you might
want to investigate further. Maybe your USB chipset/drivers use up a lot of
CPU power just transferring data over the bus? You could try running it on a
capture file instead to see if it performs differently.

You could lower the sample rate/bandwidth - no point capturing and processing
2MHz of the RF spectrum if you're dealing with a signal only 200kHz wide.
(Although admittedly the RTL2832 can't go very low in this regard.)

You could experiment with scheduling, so that the UI is given a higher
priority than the rest of the system. This way it would still appear snappy
even under high CPU load.

I'm sure there are other things you could investigate, so if you find anything
out be sure to let us know!

Cheers,
Adam.

[Ton Machielsen]

On Thu, May 10, 2012 at 12:25 PM, Adam Nielsen <a.ni...@shikadi.net> wrote:

 

However if a basic flow graph is making your PC grind to a halt, you might want to investigate further.  Maybe your USB chipset/drivers use up a lot of CPU power just transferring data over the bus?  You could try running it on a capture file instead to see if it performs differently.--

I'm not even using the RTL2832 yet. If you look at the pdf i liked to you will see that i have two wave sources summed or multiplied and 2 or 4 graphical sins.
With two it works sort of ok, stalls sometimes. With 4 it stalls after about 5 seconds of running.

I will investigate further, but i think i'm not doing anything spectacular at all so far.

Ton.

[Miguel A. Vallejo]

Adam Nielsen wrote:

>>> According to the docs, Python is only used to join the
>>> blocks together, all the actual processing is done in C
>>> using high performance libraries, which optimise code
>>> for your specific CPU

This is the theory. In practice I wonder why to glue high performance C code with a low performance interpreted language. It does not make any sense!

>>> which could explain why people complaining about poor
>>> performance all seem to be running AMD CPUs...maybe
>>> they're not well optimised yet.

GCC generates nice AMD code, so the problem is another one.

One thing I always noticed in Linux systems is the graphical interface is slow. Very slow. Damnly slow!. The same graphic card under windows runs incredibly fast, but it's sluggy under Linux. I don't know if it is a X-Free86 problem, or a QT problem, or anything else, but graphics in Linux used to be very slow compared to the same hardware running windows (of course there could be exceptions, but I have never found one)

Now GNU Radio uses exotic things like OpenGL, so I suspect if the graphical interface is not properly configured / supported / whatever, a simple FFT sink will kill your flowgraph.

Who don't use a FFT display in his flowgraphs?

>>> I think the problem is the target audience.  GNU Radio
>>> is aimed at people doing research with RF.

I'm agree. GNU Radio is not intended for "final users" in any way.

>>> I don't think anyone would normally build a DVB-T transmitter

>>> receiver in GNU Radio

http://wiki.oz9aec.net/index.php/Simple_DVB_with_Gstreamer_and_GNU_Radio

http://www.ruby-forum.com/topic/131569

Adam Nielsen wrote:

 

>>> I'm not even using the RTL2832 yet. If you look at the
>>> pdf i liked to you will see that i have two wave sources
>>> summed or multiplied and 2 or 4 graphical sins. With two
>>> it works sort of ok, stalls sometimes. With 4 it stalls after
>>> about 5 seconds of running.

See my previous paragraphs... Maybe you are experiencing a poor graphical performance, which kills GNU Radio.

[Adam Nielsen]

> This is the theory. In practice I wonder why to glue high performance C code
> with a low performance interpreted language. It does not make any sense!

It's to make it easier to build flow graphs. If GRC had to generate C code
and compile it automatically, it would be very difficult, especially on
Windows where there is no standard way of compiling programs.

They claim that gluing things together with Python incurs little speed
penalty, which could be correct if they have done it right. I haven't
investigated it, but all the Python code is doing is calling functions and
passing pointers to buffers, so I think it has minimal overhead.

You could try building a flow graph in C and compare its performance, but I am
sure it will be more difficult than using Python with GRC!

> *>>> which could explain why people complaining about poor

> >>> performance all seem to be running AMD CPUs...maybe

> >>> they're not well optimised yet.*

>
> GCC generates nice AMD code, so the problem is another one.

No, GNU Radio doesn't use GCC's optimisations. I think it uses hand-coded
assembly language, and runtime instructions to pick which routines to call
based on the CPU it is running on. If they haven't implemented support for
some AMD processors, then it will fall back to unoptimised code (i.e. it will
use normal C 'for' loops, instead of vector instructions.) See the
announcement at
http://www.trondeau.com/blog/2010/12/11/volk-vector-optimized-library-of-kernels.html

For comparison, running wbfm_mono.grc on my Intel Core2 Quad @ 2.4GHz gives me
this message in the output:

Using Volk machine: ssse3_64_orc

And it then proceeds to run with 15% CPU usage. It would be interesting to
see how other CPUs perform.

> One thing I always noticed in Linux systems is the graphical interface is
> slow. Very slow. Damnly slow!. The same graphic card under windows runs
> incredibly fast, but it's sluggy under Linux. I don't know if it is a X-Free86
> problem, or a QT problem, or anything else, but graphics in Linux used to be

> *very *slow compared to the same hardware running windows (of course there

> could be exceptions, but I have never found one)

This is always a driver issue. I can only speak for the nVidia closed source
driver as it is the only one I have used, but speed is generally not a
problem. Other drivers may not fare so well, particularly for less popular
cards. Many years ago there often were no drivers so VESA was the only
option, and that was terribly slow. But over the last few years I have heard
many complaints about buggy drivers, but none about speed. I think the
problem has generally been solved.

Cheers,
Adam.

[Miguel A. Vallejo]

Adam Nielsen wrote:

>>> No, GNU Radio doesn't use GCC's optimisations.

Since it is compiled with GCC, it uses GCC optimizations.

>>> I think it uses hand-coded assembly language, and runtime
>>> instructions to pick which routines to call based on the CPU it
>>> is running on.  If they haven't implemented support for some AMD
>>> processors, then it will fall back to unoptimised code (i.e. it will use
>>> normal C 'for' loops, instead of vector instructions.)

AMD processors implements also MMX, SSE and all those weird instructions, so this is not the problem unless you are using a 10 years old CPU.

As I said before, I don't know what is the reason. Maybe is a combination of factors, but as I said before:  No computer is enough to move GNU Radio properly.

And this is not my opinion, is a fact!

[Adam Nielsen]

> *>>> No, GNU Radio doesn't use GCC's optimisations.*

>
> Since it is compiled with GCC, it uses GCC optimizations.

Sorry I meant Volk, not GNU Radio. Volk is compiled with GCC, but the kernels
apparently use a different compiler if it's available. These use SIMD
instructions, which GCC doesn't, but only because GCC is fed different code to
ORC. GCC is told to use a loop, so it optimises that as best it can, whereas
the kernels use vector instructions so the loop is performed internally by the
CPU.

> AMD processors implements also MMX, SSE and all those weird instructions, so
> this is not the problem unless you are using a 10 years old CPU.

According to http://en.wikipedia.org/wiki/SSSE3 AMD CPUs only got these
instructions last year, whereas Intel CPUs have had them since Core2 was
introduced in 2006. So unless you have a really new AMD CPU, it looks like it
will be outperformed by a comparable Intel one.

> As I said before, I don't know what is the reason. Maybe is a combination of
> factors, but as I said before: No computer is enough to move GNU Radio properly.
>
> And this is not my opinion, is a fact!

I don't know whether it's a fact, but I do agree that SDR in general is very
taxing on CPUs. But as I said in another thread, that's because SDR is still
a fairly new field (for the general population, anyway.) Which itself is
because CPUs have only recently become fast enough to make it practical at all.

It will be very exciting to see what happens once the field matures and there
is more software and better performing hardware!

Cheers,
Adam.

[imo]

There are video cards (Nvidia, ATI) which can be used as a general purpose processors. Programmed in CUDA or OpenCL. I think it might be used for GNU Radio as well (basically as a dsp coprocessor, GPU SIMD). This may deload the main CPU. i.

[Adam Nielsen]

> There are video cards (Nvidia, ATI) which can be used as a general purpose
> processors. Programmed in CUDA or OpenCL. I think it might be used for GNU
> Radio as well (basically as a dsp coprocessor, GPU SIMD). This may deload the
> main CPU. i.

I haven't seen any reference to this, so I'm not sure GNU Radio is making use
of it yet. But it would seem to be the way to go. I'm thinking about writing
my own HDSDR-like program that will run under Linux, and build it entirely
around OpenCL/OpenGL to get the best performance possible.

Unfortunately for someone new to SDR like myself, this will be quite a
challenge :-)

Cheers,
Adam.

[Miguel A. Vallejo]

Adam Nielsen wrote:

>>> I'm thinking about writing my own HDSDR-like
>>> program that will run under Linux, and build it
>>> entirely around OpenCL/OpenGL to get the
>>> best performance possible.

OpenCL/OpenGL is not guarantee for best performance, but sure it is for weird compatibility issues...

[Adam Nielsen]

> OpenCL/OpenGL is not guarantee for best performance, but sure it is for weird
> compatibility issues...

Yes I'm beginning to discover that. It will probably mean the program is
Linux only and works on a small number of video cards!

But given the amount of data to process, it should perform better than a CPU.
In theory anyway...

Cheers,
Adam.

[Alexandru Csete]

On Thursday, 10 May 2012 10:09:09 UTC+2, Ton Machielsen wrote:

On Thu, May 10, 2012 at 4:30 AM, Adam Nielsen  wrote:

I think the problem is the target audience.  GNU Radio is aimed at people doing research with RF.  It's designed to be flexible and accurate first, and speed comes second.  I don't think anyone would normally build a DVB-T transmitter/receiver in GNU Radio, but people using it professionally might build small components of a DVB-T device to test hardware they are designing.

I agree with what you are saying, but if a VERY BASIC flow makes gnuradio grind to a halt also researchers cannot find many uses of it. I agree that my PC is not the most powerful in the world, but come on, the flow is VERY VERY basic....

You do use a throttle block when not having any hardware in the loop (c.f. bullet 7 in the PDF doc)?

Alex

[Ton Machielsen]

Yes. I followed exactly the instructions in the doc.

--

You received this message because you are subscribed to the Google Groups "Ultra Cheap SDR" group.

To view this discussion on the web visit https://groups.google.com/d/msg/ultra-cheap-sdr/-/pxDk0-78miYJ.
To post to this group, send email to ultra-c...@googlegroups.com.
To unsubscribe from this group, send email to ultra-cheap-s...@googlegroups.com.