Re: [Discuss-gnuradio] CPU Utilization and USRP2

[Josh Blum]

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

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,
> David
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio