# Gnuradio-companion and multithreading **URL:** \ **Category:** GNU Radio\ **Created:** [January 21, 2015, 4:49pm UTC](https://www.ruby-forum.com/t/gnuradio-companion-and-multithreading/233913 "2015-01-21T16:49:05Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [January 21, 2015, 4:49pm UTC](https://www.ruby-forum.com/t/gnuradio-companion-and-multithreading/233913/1 "2015-01-21T16:49:05Z")
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 ---
**Author:** ![andreas\_l](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/7bcc69/32.png) [@andreas\_l](https://www.ruby-forum.com/u/andreas_l)\ **Post date:** [January 21, 2015, 5:07pm UTC](https://www.ruby-forum.com/t/gnuradio-companion-and-multithreading/233913/2 "2015-01-21T17:07:50Z")
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: > [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) [1] Links: ---
**Author:** ![andreas\_l](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/7bcc69/32.png) [@andreas\_l](https://www.ruby-forum.com/u/andreas_l)\ **Post date:** [January 25, 2015, 7:23pm UTC](https://www.ruby-forum.com/t/gnuradio-companion-and-multithreading/233913/3 "2015-01-25T19:23:35Z")
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 ---
**Author:** ![andreas\_l](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/7bcc69/32.png) [@andreas\_l](https://www.ruby-forum.com/u/andreas_l)\ **Post date:** [January 26, 2015, 8:02pm UTC](https://www.ruby-forum.com/t/gnuradio-companion-and-multithreading/233913/4 "2015-01-26T20:02:56Z")
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. > > > 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 ---
**Author:** ![andreas\_l](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/7bcc69/32.png) [@andreas\_l](https://www.ruby-forum.com/u/andreas_l)\ **Post date:** [January 21, 2015, 5:12pm UTC](https://www.ruby-forum.com/t/gnuradio-companion-and-multithreading/233913/5 "2015-01-21T17:12:20Z")
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