Re: [Discuss-gnuradio] oprofile inband code results

[Eric Blossom]

On Sat, Oct 06, 2007 at 06:02:09PM -0400, George Nychis wrote:
> 
> 
> George Nychis wrote:
> >Heres a new and important run, where it seems like the application 
> >cannot keep up (Eric knows what I'm talking about) from the low 
> >interpolation and decimation rates, the memory usage shoots through the 
> >roof, and the system ends up locking up for a period of time:
> >
> >http://www.andrew.cmu.edu/user/gnychis/inband_tx_rx_3
> >
> >the PMT library is really sucking face with 23% of the time, surpassing 
> >libm, libc and libstdc++ which are at 22%.
> >
> >I can certainly think of ways of reducing the PMT usage... there are 
> >numerous cases where I will parse a PMT list, and pass the list to 
> >another method only to re-parse it because it is convenient rather than 
> >passing tons of parameters. :)
> >
> >- George
> >
> 
> and just to clarify, i'm not saying it would be extremely beneficial to 
> optimize the PMT use through all of the inband code... but most 
> certainly in the TX and RX chain through the inband code.  Optimizing 
> the parsing of TX and RX messages would seem key.
> 
> - George

George,

Your profile shows:

44459     2.2640  libpmt.so                
pmt_cons(boost::shared_ptr<pmt_base>, boost::shared_ptr<pmt_base>)
45992     2.3421  libusrp_inband.so.0.0.0  
usrp_usb_interface::handle_message(boost::shared_ptr<mb_message>)
51390     2.6170  libm-2.5.so              (no symbols)
56609     2.8828  libmblock.so             
mb_msg_accepter_smp::operator()(boost::shared_ptr<pmt_base>, 
boost::shared_ptr<pmt_base>, boost::shared_ptr<pmt_base>, unsigned int)
62358     3.1755  libstdc++.so.6.0.8       (no symbols)
65506     3.3358  vmlinux-2.6.20-16-generic schedule
73772     3.7568  libpmt.so                pmt_nthcdr(unsigned int, 
boost::shared_ptr<pmt_base>)
337319   17.1777  libc-2.5.so              (no symbols)

Before even thinking about libpmt, it would be wise to figure out the
much greater CPU consumption in libc.  Start with the big offenders.

When that's sorted out (and we're confident about your profile
numbers) we can have a discussion about what's next.

BTW, what is the test case that you're running?
What is the exact sequence of commands that you are issuing to
generate this trace?  I'd like to try to reproduce this on my machines.

Eric