On Mon, Jul 13, 2015 at 12:30 AM, West, Nathan <n...@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 <gnura...@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. Tom
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
