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

Hi Dennis,

if I read Fig 4 of [1] correctly, then you 32-delay DC blocker has a
passband starting at let's say 0.025 * f_sample.
I've gone ahead and clicked together a FIR filter that theoretically
should perform as well; its CPU consumption is... tolerable :)
Compare [2]; taps are in the PNG comment. Because this is so quick and
dirt, I didn't bother to verify I really see 10MS/s throughput -- but
considering the most-used CPU core is tasked 40% of its time only, I
think that's a feasible assumption; plus, you can probably go further,
if the filter performance doesn't match your needs -- I found that for
filters > 100taps numerical accuracy of single precision floating point
arithmetics starts taking its toll, so your amplitude response will not
100% be what gr_filter_design shows. Verify with a long averaging Qt
frequency sink or so.

Best regards,
Marcus

[1] http://www.ingelec.uns.edu.ar/pds2803/materiales/articulos/04472252.pdf
[2] http://i.imgur.com/Qmx9q96.png

On 21.07.2015 09:02, Dennis Glatting wrote:
> On Mon, 2015-07-13 at 21:43 -0400, Tom Rondeau wrote:
>> On Mon, Jul 13, 2015 at 12:30 AM, West, Nathan
>> <natw@ostatemail.okstate.edu> 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
>> <gnuradio@pki2.com> 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()
>
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio