[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Diagnosing the cause of D's

From: Marcus Müller
Subject: Re: [Discuss-gnuradio] Diagnosing the cause of D's
Date: Fri, 29 May 2015 20:13:38 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

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,

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?


Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]