# Which block is causing dropped samples? **URL:** \ **Category:** GNU Radio\ **Created:** [March 18, 2015, 12:08am UTC](https://www.ruby-forum.com/t/which-block-is-causing-dropped-samples/234621 "2015-03-18T00:08:21Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [March 18, 2015, 12:08am UTC](https://www.ruby-forum.com/t/which-block-is-causing-dropped-samples/234621/1 "2015-03-18T00:08:21Z")
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 ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [March 18, 2015, 12:26am UTC](https://www.ruby-forum.com/t/which-block-is-causing-dropped-samples/234621/2 "2015-03-18T00:26:48Z")
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](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) > 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: > **[UDP Transport (Sockets) - USRP Hardware Driver and Device Manual: Transport...](https://files.ettus.com/manual/page_transport.html#transport_udp)** > > The UDP transport is implemented with user-space sockets. This means standard Berkeley sockets API using send()/recv(). ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [March 18, 2015, 11:41am UTC](https://www.ruby-forum.com/t/which-block-is-causing-dropped-samples/234621/3 "2015-03-18T11:41:08Z")
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_ ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [March 18, 2015, 6:13pm UTC](https://www.ruby-forum.com/t/which-block-is-causing-dropped-samples/234621/4 "2015-03-18T18:13:53Z")
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. [removed\_email\_address@domain.invalid] Sent: Wednesday, March 18, 2015 4:39 AM To: removed\_email\_address@domain.invalid 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