|
On 05/29/2015 02:13 PM, Marcus Müller
wrote:
Hi Richard,
320kS is not the minimal rate; if I'm not mistaken it's
100MHz/512.
Ds are relatively serious, and I've rarely seen them: The typical
"your system is too slow" results in "O"verflows; typically, you
see "D" if UHD starts wondering where the sample packet n
disappeared to, after receiving n-1 followed by n+1 (or so).
What's your ethernet hardware? (If on linux, "lspci | grep -i
ether")
We've had some grief caused by USB3-to-ethernet-adapters which
seemed to take delight in confusing at least UHD, its users and a
significant part of its support team by randomly reordering
packets on a direct link. Also, there's a single Intel Gigabit
Ethernet controller that comes directly from hell, but it's
becoming rarer in the wild every day.
Best regards,
Marcus
The notorious Intel NIC is the 82579LM. It drops packets, even at
low load. It's a FIFO control bug that they couldn't ever fix...
On 05/29/2015 06:07 PM, Richard Bell
wrote:
Hi all,
I need some help determining the cause of D's being
displayed from my N210 device. I know it means GNU Radio is
not consuming the samples from my laptops Ethernet socket
buffer fast enough, causing the USRP to overflow it.
What I would like to do now, is learn how to monitor
performance such that I can figure out which part of my
receiver is the bottleneck, so I can focus on optimizations
there. I can't lower the sample rate anymore, because I'm
already at the minimum rate the USRP requires (320k).
Would someone recommend a next course of action and tools
I should download to proceed?
Appreciated,
Rich
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
|