Gnuradio-companion and multithreading

GNU Radio
1

Hi,

iam testing gnuradio-companion editor on the Bananapi LUbuntu. When i am
editing a block or drawing a block i recognize in top that the python
process has a 100% CPU (i have 2 CPUs) load. The gnuradio-companion
editor reacts very slow.

Is it possible to tell the editor or python to use 2 CPUs ? I could
remember that each gnuradio block in a project is one thread when
running an compiled grc project so it seems to possible in general.

Andreas

2

That would require wholesale reworking of GRC.

You really, really, really shouldn’t think of a lowly banana-pi as
your development environment. The .py files that are generated by GRC
can be generated on a “real” machine, and executed on the banana-pi,
provided that you have identical GR installs on both sides.

On 2015-01-21 10:47, Andreas L. wrote:

[email protected]
Discuss-gnuradio Info Page [1]

Links:

3

Hi Marcus,

Hi Andreas,

GRC is already as multithreaded as GTK applications can generally be –
I think the bottleneck here is really your Bananapi’s CPU, its RAM and
its graphics card driver.
If i stop the drawing of all the graphs in the compiled GNU Radio
application, i could change parameters like the volume or gain with the
sliders/text boxes now.

The next was to decrease the sample rate of some blocks by adjusting the
decimation.

I could not reduce the sample rate of the RTL block below 1 Msample. The
testing tool told me that sample rates below 1M are invalid for the RTL
stick. So i think the RTL source block needs the most CPU time.

All this changes reduced the overruns a lot. The CPU load decreases
about 20 % to about 170 %.

This application works in general.

To be honest, I generally consider the Raspberry Pi and similar devices
to be embedded ones with hardware that underwent optimization for
exactly this application – low cost embedded media playing linux GPIO
bitbanging computing. Not general purpose GUIs like the GRC.

Generally, the most sensible approach to using such devices with GRC I’d
say is to run GRC on your “real” PC, and transfer over the resulting
python program to your embedded device. Please don’t expect wonders from
the signal processing performance of a dual core ARM processor –
there’s only so much FLOPS you can get out of silicon…
Ok, and which processors do you suggest in general for signal processing
? Which processors are optimized for signal processing ?

Best regards,
Marcus
regards,
Andreas

4

Hi Andreas,

If i stop the drawing of all the graphs in the compiled GNU Radio
application, i could change parameters like the volume or gain with the
sliders/text boxes now.
That was to be expected :slight_smile: Calculating a 512-point FFT is somewhat
ressource-consuming, but drawing and updating a graph on a display is
much worse…

The next was to decrease the sample rate of some blocks by adjusting
the decimation.
Indeed! No matter what kind of processing you do, it generally scales
linearly with the samples per second you need to process…

I could not reduce the sample rate of the RTL block below 1 Msample.
The testing tool told me that sample rates below 1M are invalid for
the RTL stick. So i think the RTL source block needs the most CPU time.
No, not necessarily. It just means that the RTL stick won’t produce
samples at a lower rate than 1MS/s. Nothing you can do about that –
decimation from there on has to happen in software.

All this changes reduced the overruns a lot. The CPU load decreases
about 20 % to about 170 %.
This is a classical problem of engineering: You have to do something
with a given complexity, but your job is to use as little ressources as
possible.
Therefore, the first step you need to perform in your signal flow would
be decimation to the minimum viable sampling rate, which of course
depends on your signal and application.

the signal processing performance of a dual core ARM processor –
there’s only so much FLOPS you can get out of silicon…
Ok, and which processors do you suggest in general for signal
processing ? Which processors are optimized for signal processing ?
Um, that’s a broad question. There’s people doing Signal Processing on
huge clusters of blade computers, and there’s people that do signal
processing inside your run-off-the-mill hearing aid. Of course, there’s
different things you can achieve, and different amounts of flexibility
and design effort…

However, you never can have “too much” processing power. Generally,
since you’re using an RTL dongle, you can just design your application
on your PC, make it work there. Then, analyze how much power it needs,
as in an estimate of operations per second. After that, you’ll get a
feeling for which class of device you’ll need. The tricky part here is
that different architectures have different efficiencies when doing
things, and there’s a different set of optimizations for different
architectures. In essence: if your application uses 50% of the power
your quadcore i7 has, there’s no way you’ll just run the same
application on your mobile phone…

Greetings,
Marcus

5

Hi Andreas,

GRC is already as multithreaded as GTK applications can generally be –
I think the bottleneck here is really your Bananapi’s CPU, its RAM and
its graphics card driver.
To be honest, I generally consider the Raspberry Pi and similar devices
to be embedded ones with hardware that underwent optimization for
exactly this application – low cost embedded media playing linux GPIO
bitbanging computing. Not general purpose GUIs like the GRC.

Generally, the most sensible approach to using such devices with GRC I’d
say is to run GRC on your “real” PC, and transfer over the resulting
python program to your embedded device. Please don’t expect wonders from
the signal processing performance of a dual core ARM processor –
there’s only so much FLOPS you can get out of silicon…

Best regards,
Marcus