Re: [Discuss-gnuradio] Possible solution to USRP Packet Dropping

[Moses Browne Mwakyanjala]

Hello,

I did follow the recommendations provided

1. Suggestions from "USRP Host Performance Tuning Tips and Tricks" page
• I increased core.rmem_max and core.wmem_max values as suggested
  
• Set all cores to CPU governor performance
  
• I increased the number of descriptors by using the "ethtool" program
2. The buffer size on the advanced tab
• I got the following warning: "gr::log : WARN: flat - Block (xxx) max output buffer set to 8192 instead of the requested 4000000000"
3. USRP Wire Format
• Wire format: The X310 only supports otw_format sc16
• Output Type: I did change to complex int. So far, I haven't found any data conversion blocks that could convert this to complex float. I suppose one has to write the converter from scratch?

I suppose profiling the flowgraph will eliminate some of the bottlenecks if I could find out which block consumes the most resources. Is there any tool that could tell profile my grc flowgraph and point out the culprits? 

Regards,

Moses. 

On Wed, Aug 14, 2019 at 7:39 PM Nate Temple <address@hidden> wrote:

Hi Moses,

Depending upon what you're doing, you could use a sc16 data type instead of fc32. You can change this in the UHD USRP Source block, and will cut your data rate in half.

Also, make sure you've done the few things outlined in this app note: https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks


Regards,
Nate Temple

On Wed, Aug 14, 2019 at 10:22 AM Marcus D. Leech <address@hidden> wrote:

On 08/14/2019 01:14 PM, Moses Browne Mwakyanjala wrote:

Hello everyone, 

I'm experiencing packet dropping when I operate the USRP X310 (1GBe, 1472 bytes buffer) at high sample rates (around 20 MSamples/Second). This severely limits the nominal bit rate I was hoping for. Over a year ago, I stumbled upon a presentation [1] where the presenter was able to go around the problem by creating a block he called buffer. Basically, this block converts high rate complex IQ samples into 2-byte char and store them somewhere in RAM. The data is then released at a low-enough rate such that subsequent blocks cause no overflows. Sadly, the code is not public and I was thinking of writing a similar block myself. I'm looking for ideas on how to efficiently reproduce his results. All suggestions are highly welcomed. 

Regards,

Moses.  

The problem with any buffering approach is that if your host system cannot, on average, "keep up", your buffers will slowly fill up, since they
  aren't being drained as fast as they are being filled.

You need a faster computer, or a more-efficient processing flow.   No amount of buffering will help you, unless you're doing short
  captures.  But for continuous capture/streaming, buffering cannot help you.

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

bpsk_srrc_nrz.grc.png
Description: PNG image