On Thu, Nov 04, 2010 at 03:07:42PM -0500, Marc Epard 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, I like to use oprofile. It's packaged for Fedora and Ubuntu (and probably the rest). It gets the job done using the h/w performance counters, and as such, the measurement doesn't perturb the "regular" execution time, and there's no need to recompile with special options. It would be a great tool to use on this UHD problem to get a better idea of exactly where the cycles are getting burned. http://oprofile.sourceforge.net/docs On Fedora 13: $ rpm -qa | grep -i oprofile oprofile-0.9.6-6.fc13.x86_64 oprofile-gui-0.9.6-6.fc13.x86_64 Eric > 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 Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
