[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] CPU Utilization and USRP2
From: |
Tom Rondeau |
Subject: |
Re: [Discuss-gnuradio] CPU Utilization and USRP2 |
Date: |
Thu, 4 Nov 2010 17:16:36 -0400 |
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
>