Which block is causing dropped samples?

GNU Radio
1

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

2

On 03/17/2015 07:06 PM, Anderson, Douglas J. wrote:

So my question is, is there an easy (or hard, I don’t really care) way
Discuss-gnuradio Info Page
The ‘D’ message is coming from the UHD driver itself–long before it
gets to the guts of your flow-graph. That happens, though, when the app
layer cannot
“keep up” with the sample stream coming from the kernel, because its
average offered load is higher than the average available compute and
memory bandwidth.

If you’re on Linux have you set the recommended buffering parameters in
the network stack:

http://files.ettus.com/manual/page_transport.html#transport_udp

3

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

4

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+danderson=removed_email_address@domain.invalid
[discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalid] on behalf
of Marcus M. [[email protected]]
Sent: Wednesday, March 18, 2015 4:39 AM
To: [email protected]
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_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