# Testing an GRC project runs nearly 200% CPU

**URL:** <https://www.ruby-forum.com/t/testing-an-grc-project-runs-nearly-200-cpu/233839>\
**Category:** GNU Radio\
**Created:** [January 15, 2015, 10:39pm UTC](https://www.ruby-forum.com/t/testing-an-grc-project-runs-nearly-200-cpu/233839 "2015-01-15T22:39:59Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**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 15, 2015, 10:39pm UTC](https://www.ruby-forum.com/t/testing-an-grc-project-runs-nearly-200-cpu/233839/1 "2015-01-15T22:39:59Z")

</div>

Hi,

iam testing an UKW Radio Receiver GRC project (gr-rds) on bananapi. The  
application starts. The tuned radio station sounds clicking. Changing  
any parameter in the GUI is very difficult/slow.

top tells me a memory usage about 20 %. CPU usage is nearly 200 %  
(bananapi has 2 CPUs). At any webside i read that working with no  
throttle blocks could run a CPU to maximum. In my project which iam  
testing i see no throttle blocks. I am not sure if that could be the  
reason because iam working on the bananapis real hardware ?

Is there something wrong with the sample rate ?

Andreas

---

<div class="post-metadata">

**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 15, 2015, 11:26pm UTC](https://www.ruby-forum.com/t/testing-an-grc-project-runs-nearly-200-cpu/233839/2 "2015-01-15T23:26:04Z")

</div>

Post a screenshot of your flowgraph. Sounds like a sample rate mismatch.

On Fri, Jan 16, 2015 at 8:38 AM, Andreas L.

---

<div class="post-metadata">

**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 16, 2015, 1:00am UTC](https://www.ruby-forum.com/t/testing-an-grc-project-runs-nearly-200-cpu/233839/3 "2015-01-16T01:00:00Z")

</div>

Hello Andreas,

you never need a throttle block when you have hardware that  
limits/defines your real-world sampling rate; in your case, it’s your RF  
hardware and your sound card.  
Aside from things like implicit resampling in the audio card driver  
infrastructure, it’s absolutely possible that your bananapi is simply  
not performant enough to do GUI, signal processing and audio playback at  
once.  
The question is: Does the same application work sufficiently well on a  
fast PC? Do you see any over- or underrun warnings on your console?

Greetings,  
Marcus

---

<div class="post-metadata">

**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 16, 2015, 8:20am UTC](https://www.ruby-forum.com/t/testing-an-grc-project-runs-nearly-200-cpu/233839/4 "2015-01-16T08:20:46Z")

</div>

On 01/16/2015 12:58 AM, Marcus M. wrote:

> Hello Andreas,
> 
> you never need a throttle block when you have hardware that  
> limits/defines your real-world sampling rate; in your case, it’s your RF  
> hardware and your sound card.  
> Aside from things like implicit resampling in the audio card driver  
> infrastructure, it’s absolutely possible that your bananapi is simply  
> not performant enough to do GUI, signal processing and audio playback at  
> once.

Resamplers are often performance killers.

M

---

<div class="post-metadata">

**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 16, 2015, 9:29am UTC](https://www.ruby-forum.com/t/testing-an-grc-project-runs-nearly-200-cpu/233839/5 "2015-01-16T09:29:19Z")

</div>

* * *

Discuss-gnuradio mailing list  
removed\_email\_address@domain.invalid  
[https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio)

---

<div class="post-metadata">

**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 16, 2015, 3:19pm UTC](https://www.ruby-forum.com/t/testing-an-grc-project-runs-nearly-200-cpu/233839/6 "2015-01-16T15:19:20Z")

</div>

* * *

Discuss-gnuradio mailing list  
removed\_email\_address@domain.invalid  
[https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio)

---

<div class="post-metadata">

**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 16, 2015, 9:44am UTC](https://www.ruby-forum.com/t/testing-an-grc-project-runs-nearly-200-cpu/233839/7 "2015-01-16T09:44:45Z")

</div>

Hi Andreas,

that’s kind of interesting, because if it works on a PC, I’d say it’s a  
performance issue; if you don’t see aU (audio underruns) or some osmosdr  
warnings, then I’d say it’s not.  
What one does in this situation is both running a process-based cpu  
usage tool; I recommend “htop” (which is like top, but actually a lot  
nicer). Do you have another process suddenly consume CPU? Does it look  
like it’s pulseaudio (that would be the implicit audio resampling  
issue)?  
If, what I presume, you only see two python processes consuming 100%  
each, you will need to dig deeper. There’s a tool called “perf” [1],  
which, when run as “perf top” as root will let you introspect CPU usage  
per method, including kernel routines.  
Both perf and htop are available as packets for many Linux  
distributions.

Best regards,  
Marcus  
[1] [Tutorial - Perf Wiki](https://perf.wiki.kernel.org/index.php/Tutorial)

---

<div class="post-metadata">

**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 17, 2015, 3:13pm UTC](https://www.ruby-forum.com/t/testing-an-grc-project-runs-nearly-200-cpu/233839/8 "2015-01-17T15:13:59Z")

</div>

Hi Vanush,

attached you could find the screenshot of the flowgraph.

Andreas

---

<div class="post-metadata">

**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 16, 2015, 3:49pm UTC](https://www.ruby-forum.com/t/testing-an-grc-project-runs-nearly-200-cpu/233839/9 "2015-01-16T15:49:03Z")

</div>

Hi Andreas,

> Yes i remember a lot of such characters on the console. Is the sample  
> rate of the audio device to small ?  
> in some way or another, yes.  
> Explanation: A sound card consumes a fixed about of samples per second  
> (e.g. 48,000), that we shall call f\_sample,soundcard  
> You need to supply these in time, and if you don’t, your sound will be  
> choppy and you’ll see aU.

The fact that you’re not doing that in time can have two reasons  
(actually three reasons[1]):

1. systematically: You take your RF samples from your SDR peripheral,  
and you process it, decimating it to a fixed rate of f\_sample,RF \<  
f\_sample,soundcard.
2. computationally: although your theoretical flow graph does the right  
thing, ie. f\_sample,RF / decimation == f\_sample,soundcard, your computer  
can’t process these samples in time, and your sound card has to wait for  
these samples. Since the real world time keeps running on, it can’t  
produce sound.
3. real physics don’t like anybody: both the sound card and your RF  
hardware have oscillators from which they generate their sampling rates;  
these oscillators will neither be perfect nor will they be coherent, so  
inevitably there will be some mismatch between the expected and actual  
sampling rates. However, these offsets tend to be small and would  
usually not lead to massive accumulations of audio underruns.

So, since the same application works on a faster machine, I’d say it’s  
2). What you could check, though, is that the sampling rate you set in  
your audio sink is actually supported by the hardware, and try with  
different values (e.g. 44,100 Hz instead of 48,000, but that’s about it  
when it comes to usual sampling rates), but you’d of course have to  
adjust your decimation between RF hardware and sound card accordingly.

Greetings,  
Marcus

[1] [http://youtu.be/7WJXHY2OXGE?t=40](http://youtu.be/7WJXHY2OXGE?t=40)