Performance drop with upgrade to 3.7

GNU Radio
#1

Hi - I just upgraded to 3.7.3 using the build-gnuradio script from
3.6.5.1.
I am using it to run a C++ App that captures all the radio
communications
on a Moto SmartNet system. I upgraded all my code to work with the 3.7
naming scheme and got everything to compile and run. Everything runs in
3.7, but I am seeing a lot more CPU usage, almost a whole additional
core.

Are there an obvious things I should check where blocks changed
significantly from 3.6 to 3.7?

The main code is here:
https://github.com/robotastic/smartnet-recorder/tree/3.7

And the codec is here:
https://github.com/robotastic/gr-dsd/tree/3.7

I put together the general flow graph below. Are there any blocks where
I
could be shooting myself in the foot? Is it better to do xlating or
sig_source & multiply_cc? The source bandwidth is 5MHz.

Decode Control Channel: [
https://github.com/robotastic/smartnet-recorder/blob/3.7/smartnet.cc ]
multiply_cc ( OsmoSDR(HackRF) + analog::sig_source_c )
gr::filter::fir_filter_ccf
gr::digital::fll_band_edge_cc
gr::analog::pll_freqdet_cf
gr::digital::clock_recovery_mm_ff
gr::digital::binary_slicer_fb
gr::digital::correlate_access_code_tag_bb
smartnet_deinterleave
smartnet_crc

Decode digital voice channel: [
https://github.com/robotastic/smartnet-recorder/blob/3.7/logging_receiver_dsd.cc]
tb->connect( OsmoSDR(HackRF) )
gr::filter::freq_xlating_fir_filter_ccf
gr::filter::rational_resampler_base_ccf
gr::analog::quadrature_demod_cf
gr::filter::fir_filter_fff
dsd_make_block_ff [
https://github.com/robotastic/gr-dsd/blob/3.7/lib/dsd_block_ff.cc ]
gr::blocks::wavfile_sink

#2

On Mon, Mar 24, 2014 at 7:17 AM, Luke B. [email protected] wrote:

https://github.com/robotastic/smartnet-recorder/tree/3.7
multiply_cc ( OsmoSDR(HackRF) + analog::sig_source_c )
https://github.com/robotastic/smartnet-recorder/blob/3.7/logging_receiver_dsd.cc

What processor and OS are you running on? I suggest you start by
profiling your flowgraphs with something like oprofile/perf or control
port. Profiling with 3.7 is the first step and may be all that’s
necessary if something really stands out, otherwise comparing results
of 3.6.5.1 and 3.7 would be good.

I’d be interested in seeing your results.

Nathan

#3

Thanks - I am running an quad-core Intel I5 laptop. It is running Ubuntu
13.10. I also have it running on a VM on my 8 Core I7 Macbook.

Do you have any pointers or links on using oprofile with gnuradio? I
found
some material on using GR Performance Counters, but I haven’t had a
chance
to try.

I am going to working on learning how to profile using the VM. In the
meantime, I rolled back the bare metal machine so I can keep my site up.

I installed 3.7 using the build-gnuradio script. When I reinstalled
3.6.5,
also using build-gnuradio, the performance was still high. I am
wondering
if it actually has something to do with libraries being upgraded. I know
the script upgraded me from Boost 1.49 to 1.53. Are there some other
libraries that could have a perf impact? ITPP?

On Mon, Mar 24, 2014 at 11:35 AM, West, Nathan

#4

Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

#5

Thanks Guys! I am rebuilding with Debug turned on and I also enabled
Control Ports in the compile. Hopefully this should help highlight the
major CPU hogs.

Marcus - build-gnuradio is an awesome script. Thank you so much for the
time you put into keeping it current. It is the only reliable way I have
found to install GnuRadio on Ubuntu 13.10.

  • Luke
#6

On Tue, Mar 25, 2014 at 2:27 PM, Luke B. [email protected] wrote:

I installed 3.7 using the build-gnuradio script. When I reinstalled 3.6.5,
also using build-gnuradio, the performance was still high. I am wondering if
it actually has something to do with libraries being upgraded. I know the
script upgraded me from Boost 1.49 to 1.53. Are there some other libraries
that could have a perf impact? ITPP?

I’m not sure what release type build-gnuradio is using, but you want
to do a build that preserves symbols. After that the easiest way I
know of to get a quick glance at what’s causing performance issues is
to run ‘perf top’. Just run your flowgraph then start up perf top and
whatever is hogging CPU will rise to the top of the list

Nathan