[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 12:45:55 EDT 2013

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.


Now when I configure to stream simultaneously from both DDCs on the
motherboard, the conversion task spikes to 100% cpu utilization, the
main() thread spikes to 100%, while my application thread uses about the
same percentage as before. I have the main() thread blocked in a
boost::this_thread::sleep() and most of the cpu time is kernel. Strace
shows just the sleep calls in that thread and rapid sched_yield() calls
in the conversion thread. The behavior at 1 MSPS is nearly the same as
10 MSPS. I am not seeing any non-zero error codes in the packet


Any ideas what might be causing this behavior? 


I create an rx_streamer for two receive channels (0 and 1) on the same

    // Create stream arguments

    uhd::stream_args_t stream_args(m_stream_args);

    // Add all channels

    size_t num_channels = m_usrp->get_rx_num_channels();

    for (size_t i = 0; i < num_channels; ++i)




    uhd::rx_streamer::sptr rx_stream =


and stream continuously:


    uhd::stream_cmd_t stream_cmd(


    stream_cmd.num_samps  = 0;

    stream_cmd.stream_now = 0;

    // start on a second boundary. Round up to avoid a race.

    uhd::time_spec_t cur_time = m_usrp->get_time_now();

    int offset = 1;

    if (cur_time.get_frac_secs() > 0.5)


        offset += 1;


    uhd::time_spec_t start_time =
uhd::time_spec_t(cur_time.get_full_secs() + offset);


    stream_cmd.time_spec = start_time;




Conversion thread stack trace:

(gdb) back

#0  0x0000003f286cf3a7 in sched_yield () from /lib64/libc.so.6

#1  0x00007ffff691bae9 in
long) ()

   from /opt/radiomap/lib64/libuhd.so.003

#2  0x00007ffff69e2d33 in task_impl::task_loop(boost::function<void
()()> const&) ()

   from /opt/radiomap/lib64/libuhd.so.003

#3  0x00007ffff6fbcc90 in thread_proxy () from

#4  0x0000003f29207851 in start_thread () from /lib64/libpthread.so.0

#5  0x0000003f286e890d in clone () from /lib64/libc.so.6




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130401/ceadb53a/attachment-0002.html>

More information about the USRP-users mailing list