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

Josh Blum josh at ettus.com
Mon Apr 1 23:06:15 EDT 2013



On 04/01/2013 06:27 PM, Pruitt, Paul N. wrote:
> 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
> b/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();
>                  boost::this_thread::yield();
> +               // pnp throttle
> +
> boost::this_thread::sleep(boost::posix_time::microseconds(10));
>              }
>          }
> 
> 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.
> 

Good idea actually :-)

This is a four line patch to serialize the conversions, no extra
threads: http://pastebin.com/0Q2UDB8x

I will try to get back to you in the morning using something with
condition variables.

-josh

> Paul
> 
> -----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.
> 
> -josh
> 
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 




More information about the USRP-users mailing list