[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 13:43:06 EDT 2013
Thank you for the prompt response!
Some background disk writes occur while streaming in this particular
application. With a single channel, that disk I/O "keeps up." When I
attempt to stream two simultaneous channels, even at lower aggregate
rates, it doesn't. Also, the system becomes unresponsive at times
during two-channel tests.
Though the conversion thread does run at realtime (SCHED_RR) priority,
it is very odd that the added CPU load would affect the system like
that. The software is running on a quad-core/8-thread Core i7 laptop
with several idle cores/threads. I am using Centos 6.4 and their 2.6.32
kernel, which is pretty old.
Now I see the yields in reusable_barrier. You would swap the barrier in
converter_thread_task() with condition variables? If you'd be willing to
sketch out what I should change, I will test it out and report back.
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);
> 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
USRP-users mailing list
USRP-users at lists.ettus.com
More information about the USRP-users