[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);
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.

 

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
metadata.

 

Any ideas what might be causing this behavior? 

 

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

    // 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)

    {

        stream_args.channels.push_back(i);

    }

    uhd::rx_streamer::sptr rx_stream =
m_usrp->get_rx_stream(stream_args);

 

and stream continuously:

    

    uhd::stream_cmd_t stream_cmd(

        uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);

    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;

    m_usrp->issue_stream_cmd(stream_cmd);

 

 

Conversion thread stack trace:

(gdb) back

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

#1  0x00007ffff691bae9 in
uhd::transport::sph::recv_packet_handler::converter_thread_task(unsigned
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
/opt/boost_1_44_0/lib/libboost_thread.so.1.44.0

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

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

 

Thanks!

Paul

-------------- 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