On 03/17/2015 07:06 PM, 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
[email protected]
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:
http://files.ettus.com/manual/page_transport.html#transport_udp
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
