Re: [Discuss-gnuradio] gnuradio-companion and multithreading

[Marcus Müller]

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 :) 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.
>
> 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 ?
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