Re: [Discuss-gnuradio] Which block is causing dropped samples?

[Marcus Müller]

Hi Doug,

I've personally grown fond of the perf tool that should be available for about any reasonable linux distro out there [1]; it's usage would be something like

sudo sysctl kernel/perf_event_paranoid=-1   ### note: I'm telling you to allow any user to introspect process behaviour.
perf record -a python signal_source_to_head_to_null_sink.py
perf report

And the result would be something that gives you the time spent in individual symbols (aka. functions):

  30.65%  sig_source_c3    libgnuradio-analog-3.7.6.so.0.0.0   [.] gr::analog::sig_source_c_impl::work
   3.99%  head2            libc-2.20.so                        [.] __memcpy_sse2_unaligned
   1.58%  swapper          [kernel.kallsyms]                   [k] intel_idle
   1.28%  python           libc-2.20.so                        [.] _IO_getc
   1.05%  swapper          [kernel.kallsyms]                   [k] __hrtimer_start_range_ns
   0.83%  swapper          [kernel.kallsyms]                   [k] _raw_spin_unlock_irqrestore
   0.80%  python           libpython2.7.so.1.0                 [.] 0x00000000001109e4
   0.69%  python           libpython2.7.so.1.0                 [.] 0x0000000000110a34
   0.65%  head2            libgnuradio-runtime-3.7.6.so.0.0.0  [.] gr::block_executor::run_one_iteration
   0.58%  python           libpython2.7.so.1.0                 [.] PyObject_Malloc
   0.53%  python           libpython2.7.so.1.0                 [.] 0x000000000007eeab
   0.53%  python           libpython2.7.so.1.0                 [.] PyEval_EvalFrameEx
   0.52%  python           libpython2.7.so.1.0                 [.] PyDict_Next
   0.47%  swapper          [kernel.kallsyms]                   [k] menu_select
   0.44%  swapper          [kernel.kallsyms]                   [k] __schedule
   0.44%  python           libpython2.7.so.1.0                 [.] 0x0000000000110d94
   0.42%  head2            libpthread-2.20.so                  [.] pthread_mutex_unlock
   0.41%  swapper          [kernel.kallsyms]                   [k] cpu_startup_entry
   0.40%  python           ld-2.20.so                          [.] do_lookup_x

and so forth. Clearly, my signal source is dominating the flow graph's CPU load. Memcpy comes in second, but strangely it uses the unaligned version, though it definitely will only copy at 64bit aligned addresses (complex float items, and the buffer should be page aligned). hm...

Greetings,
Marcus

[1] disclaimer: I don't consider any distro to be *sane*, and few to be *reasonable*

On 03/18/2015 12:06 AM, Anderson, Douglas J. wrote:

Hi all,

I just finished writing a flowgraph with a few custom C++ blocks, but when I connect it to a USRP N210 at about 25MS/s it's not too hard to find a combo of parameters that will cause a sea of DDDDDDDDDDs to come flooding into the term.

I think there are some areas I can improve in my blocks but I want to make sure I'm focusing on the worst-performing areas first.

So my question is, is there an easy (or hard, I don't really care) way to figure out which block in a flowgraph is causing the dropped samples? I already checked that it's not an internet issue.

Thanks in advance!

-Doug

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