[USRP-users] High CPU utilization (100%) when streaming two concurrent channels regardless of sample rate

Pruitt, Paul N. PAUL.N.PRUITT at saic.com
Mon Apr 1 19:27:07 EDT 2013

I perpetrated this egregious, one-line hack to see the effect on CPU
utilization for my two-channel streaming case:

diff --git a/host/include/uhd/utils/atomic.hpp
index 7a81d8d..0868447 100644
--- a/host/include/uhd/utils/atomic.hpp
+++ b/host/include/uhd/utils/atomic.hpp
@@ -100,6 +100,8 @@ namespace uhd{
                 if (_count.read() == boost::uint32_t(~0))
                     throw boost::thread_interrupted();
+               // pnp throttle

With the 10 usec delay in the loop, the CPU utilization went from two
tasks at 100+% each to 40% and 27% respectively at 10 MSPS * 2 channels.
No overruns. Load average much lower.
I am letting it run for a while.


-----Original Message-----
From: USRP-users [mailto:usrp-users-bounces at lists.ettus.com] On Behalf
Of Josh Blum
Sent: Monday, April 01, 2013 1:14 PM
To: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] High CPU utilization (100%) when streaming two
concurrent channels regardless of sample rate

On 04/01/2013 11:45 AM, Pruitt, Paul N. wrote:
> I am using an N210 with this software configuration:
>     linux; GNU C++ version 4.4.6 20120305 (Red Hat 4.4.6-4); 
> Boost_104400;
>     UHD_003.005.000-27-gfcfcc01f
> When I stream data from one DDC using sc16 wire format at 1 MSPS, 
> according to htop, the CPU utilization is ~1% for the conversion 
> thread and nearly the same for the application thread that receives 
> the data and currently does nothing with it. At 10 MSPS, the CPU 
> utilization is 16% for each of these threads. Very reasonable.

The n>1 converter threads are actually spinning and thread yielding when
there are multiple channels per streamer. So, one of the effects is that
you would see CPU usage climb up for the core hosting that thread.

Is it a problem BTW? This could be addressed with condition variables
pretty easily.


USRP-users mailing list
USRP-users at lists.ettus.com

More information about the USRP-users mailing list