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
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
