[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] CPU Utilization and USRP2

From: Josh Blum
Subject: Re: [Discuss-gnuradio] CPU Utilization and USRP2
Date: Thu, 04 Nov 2010 12:23:36 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101027 Thunderbird/3.1.6

Well, there is extra overhead. A "pirate" thread in the the receive path spins on the socket and inspects the contents. The packet may be an asynchronous message packet for flow control or destined for the user. Or it may be a data packet, in which case it is placed into a queue to be popped off by the device::recv() call. No extra memcopies, its just managing pointers.

Could this pirate thread be removed? If the async messages came in over a different UDP port, and the multi-device buffer alignment logic was re-written to be event driven (when recv() is called). Then yes. And I will probably implement this when I get the time. :-)

So, my best guess is that you are mostly seeing the overhead of the thread inspecting the packets. Of course there is also additional overhead added by using UDP, parsing VRT packets, parsing inline message packets.

Thanks for testing it out BTW!

On 11/04/2010 10:46 AM, David Campbell wrote:
Hi All,
    I've noticed that the C++ interfaces provided in gnu-radio and UHD for usrp2
data streaming are CPU-intensive (UHD moreso than gnu-radio).  I am wondering if
there are easy ways to mitigate this or are there plans in the future to
diminish these.  For UHD a decimate by 16 process chews up 75% of a CPU just on
the uhd::device::recv functiion (not much less even when I use
RECV_MODE_FULL_BUFF and size the buffer to be 100x the size of a single
packet).  For gnuradio's  the CPU utilization is more like 36% - still a lot.

   I may try to recode some of the lower-level interfaces in UHD if there is not
an easy way to help improve CPU utilization.

   Thanks for your help,

Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]