|
From: | Anderson, Douglas J. |
Subject: | Re: [Discuss-gnuradio] Which block is causing dropped samples? |
Date: | Wed, 18 Mar 2015 17:11:45 +0000 |
M. Leech, I had set up the transport settings, but thanks for clarifying what actually causes the D, that was an important point for me to understand.
M. Muller, I haven't used the perf tool but that's exactly the kind of thing I was looking for. I'll take a look.
Thanks gentlemen!
-Doug
From: discuss-gnuradio-bounces+address@hidden [discuss-gnuradio-bounces+address@hidden on behalf of Marcus Müller address@hidden
Sent: Wednesday, March 18, 2015 4:39 AM To: address@hidden Subject: Re: [Discuss-gnuradio] Which block is causing dropped samples? 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_xand 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:
|
[Prev in Thread] | Current Thread | [Next in Thread] |