Re: [Discuss-gnuradio] Run graph/ scheduler overhead

[Dennis Glatting]

On Mon, 2015-07-13 at 21:43 -0400, Tom Rondeau wrote:
> On Mon, Jul 13, 2015 at 12:30 AM, West, Nathan
> <address@hidden> wrote:
>         This is a lot of information, and I'm just going to pick out
>         one statement to comment on.
>         
>         On Sun, Jul 12, 2015 at 6:13 PM, Dennis Glatting
>         <address@hidden> wrote:
>                 
>                 If I remove most of the blocks from my graph with the
>                 result:
>                 
>                   source --> dc block --> Preamble --> null
>                 
>                 with the statement:
>                 
>                       return noutput_items;
>                 
>                 at the beginning of general_work() in Preamble, I have
>                 overflows and
>                 gr-perf-monitorx shows a thick red line from:
>                 
>                  optimize_c0 -> hack_rf_source_c0 -> dc_blocker_cc0
>                 --> Preamble
>                 
>                 with dc_blocker_cc0 depicted as a large blue square.
>                 
>                 
>         
>         
>         Hi Dennis,
>         
>         
>         The size (area) of the blue boxes is proportional to the
>         amount of CPU a block is using. The "darkness" and thickenss
>         of lines are how full buffers are. That indicates that DC
>         blocker is using a lot of CPU and the buffers in front of it
>         are full because the blocks have done all of their work and
>         have filled their buffers before dc blocker can work on them.
>         
>         
>         1.6ms is a long time to be working on samples when your
>         incoming rate is 10Msps.
>         
>         
>         There's a number of ways to proceed. You can use offset tuning
>         to remove the DC spike (I can't remember hackrf's input
>         bandwidth so this may or may not be realistic), use some other
>         method for DC removal, or try to optimize whatever might be
>         taking a while in the dc_blocker. (I suggest a dynamic
>         analysis tool like kcachegrind, AMD Code Analyst, or Intel
>         vTune)
>         
>         
>         A quick glance at the code makes me suspicious off the deque
>         that is used in a for loop in work. Time for my wild
>         speculation: it's possible there is some dynamic
>         allocation/dellocation gone wild with the way this deque is
>         implemented combined with this usgae. It seems like a fixed
>         length buffer (or a deque/vector with overwriting/manual
>         pointer management) would be sufficient as long as you're
>         willing to do the pointer math. It's worth looking at how
>         other blocks might be keeping internal vectors of samples and
>         possibly doing the dynamic code analysis to confirm it is the
>         deque.
>         
>         
>         -Nathan
> 
> 
> Yeah, that DC blocker turned out to be an interesting lesson in DSP.
> That's based on a paper claiming it to be a very fast algorithm for
> removing DC from a system. But like a lot of implementations in DSP,
> it was really geared towards being a hardware implementation and turns
> out to not be so great in software. It's there because it provides
> good control over the shape of the DC rejection profile in frequency,
> but computationally, there are better ways to go about this.
> 

FYI and following up. 

I simplified my graph (below). According to gr-perf-monitorx, and
gr-ctrlport-monitor agrees, 95% of the the time is spent in
dc_blocker_cc.

I haven't look at why but clearly that's a problem.



#!/usr/bin/env python
#
# Copyright (c) 2015 Dennis Glatting
#
# Build a receiver, minus all of the fancy GUI stuff, for debug/test.
#
#
# $Log: test.py,v $
# Revision 1.1  2015/07/12 08:37:29  dennisg
# Initial revision
#
#

import math
import sys

from gnuradio import gr,blocks,filter
import osmosdr
import adsb

# A bunch of constants.
#

rx_rate =   10000000.0
rx_freq = 1090000000.0
rx_gain =         47.57
rx_thr  =          4.8
rx_bits =         12


# Allocate a bunch of blocks.
#
        
tb    = gr.top_block()
src   = blocks.file_source(gr.sizeof_gr_complex,"samp.bin",True)
dc    = filter.dc_blocker_cc( 32, True )
rxcvr = osmosdr.source( "hackrf" )
pream = adsb.Preamble(rx_rate, rx_thr, rx_bits, rx_freq, rx_gain)
null  = blocks.null_sink(gr.sizeof_float)

# Do a bunch of sets.
#

rxcvr.set_sample_rate( rx_rate )
rxcvr.set_center_freq( rx_freq )
rxcvr.set_gain( rx_gain )

# Connect things up.
#

tb.connect( rxcvr, dc )
tb.connect( dc, pream ),
tb.connect(( pream, 0 ), null )



tb.run()