discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Diagnosing the cause of D's


From: Johnathan Corgan
Subject: Re: [Discuss-gnuradio] Diagnosing the cause of D's
Date: Fri, 29 May 2015 09:48:50 -0700

On Fri, May 29, 2015 at 9:07 AM, Richard Bell <address@hidden> wrote:
 
What I would like to do now, is learn how to monitor performance such that I can figure out which part of my receiver is the bottleneck, so I can focus on optimizations there. I can't lower the sample rate anymore, because I'm already at the minimum rate the USRP requires (320k).

Would someone recommend a next course of action and tools I should download to proceed?

There are many potential sources of problems that can result in overflow from the USRP. Some common ones:

- Insufficient network stack buffering in the OS. Increasing this, however, may just be masking the real problem, and at the data rate you are describing, is unlikely the issue.

- One of the blocks in the flowgraph is exceeding the CPU resources available in a single core.  While all GNU Radio blocks run in their own threads and area scheduled by the OS onto as many cores as are available, due to their sequential data dependencies, a single "slow" block can become the rate-setting portion of the flowgraph.  Normally, you always want the hardware to have this role.

- OS operations like periodic file system flushing can often consume CPU and I/O bandwidth that competes with the flowgraph.  This is made much worse if you are writing to disk as a result of the flowgraph processing.

A coarse view of the flowgraph resource usage (CPU, etc.) can be had with a thread and core aware tool like "htop".  This will quickly show if a single block/thread has become a CPU bottleneck.

A more granular view can be seen with the "perf" tool available in the linux-tools package. This allows profiling CPU usage by function and can identify hot spots for further optimization.

Finally, it might help to understand if the overflow events are "a few every so often", or continuous.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
Intro to SDR Classes - June 4-5, Columbia MD, June 29-30, El Segundo, CA
http://corganlabs.com

reply via email to

[Prev in Thread] Current Thread [Next in Thread]