Re: [Discuss-gnuradio] CPU Utilization and USRP2

[Tom Rondeau]

On Thu, Nov 4, 2010 at 4:07 PM, Marc Epard <address@hidden> wrote:
> This reminds me of a question. What do you guys use for profiling native code 
> on Linux? I have a lot more experience on Mac OS where we have Shark, 
> Instruments and the like.
>
> -Marc

Generally, I've used Oprofile. I have recently been exploring
cachegrind and callgrind (with valgrind) for use with Kcachegrind. I'm
really liking how it displays the results, but I'm still fairly new
with it (note: you can also use Kcachegrind with oprofile output).

Tom



> On Nov 4, 2010, at 2:23 PM, Josh Blum wrote:
>
>> 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
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>