Dear USRP users,

I have been using a GNU Radio Companion model to generate a signal at 200 MHz, which is then transmitted using the NI-X410. The connection between the controlling PC and the USRP is established through a QSFP28 link. Despite utilizing this high-speed Ethernet connection, I am experiencing numerous underflow and overflow issues.

Does anyone have insights into what might be causing these problems?

Best regards

Ali Kariminezhad

Hello!

I tried everything with the recommended settings and I also only got 61.44 MS/s with GNU Radio and the X410. It looks like the limiting factor here is GNU Radio. I think it might be because of the scheduler and the one thread per block policy of GR.

The first thing you should do is check whether the UHD Benchmark is working for you without any underflows.

For example, you can try this:

$ sudo ./benchmark_rate

--args "type=x4xx,addr=192.168.10.2,mgmt_addr=<IPaddr>,master_clock_rate=250e6,use_dpdk=1"

--priority "high"

--multi_streamer

--duration 60

--channels --rx_rate 250e6

--rx_subdev "B:1"

--tx_rate 250e6

--tx_subdev "A:0"  

A straightforward experiment that can be conducted in GNU Radio is to set a Signal Source or File Source in front of a Null Sink and evaluate its throughput with the Probe Rate Block.

[Source] --> [Probe Rate] --> (log) [Message Debug]
         \
	  \--> [Null Sink]

The configuration should yield throughput of at least 250 MS/s, depending on the host workstation in use. (I even achieved 618 MS/s.) Then, the null sink was replaced with the USRP sink (use the same args as above), and the benchmark was repeated with different decimations of the bandwidth. No more underflows were observed at the previously mentioned 61.44 MS/s.

The optimal approach may vary depending on the specific application. In some cases, it may be beneficial to pre-generate the waveform in GNU Radio and transmit it using a UHD-only application.

Best regards,
Sebastian Schröder

Hey Marcus,

In the last months I tried to develop a simple testbench at high bandwidths with GNU Radio and the X410 for my bachelor thesis.

You are right, the problem is twofold, first the source has to keep up with the requirements of the source, and second the USRP sink has to work at the throuput rates of the required bandwidth.

The first can be tested with the described method to measure the generated samples per second with the Probe Rate block.

For the thesis, I also did some single block throuput measurements, like you also once did for the GR source blocks (https://wiki.gnuradio.org/index.php?title=Random_Source#Computational_Performance).

The file source worked quite well for me with up to 5.3 GS/s (!) from a M.2 SSD or a RAM disk.

All other random sources (Random Source, Random Uniform Source and GLFSR Source) also worked well with over 400 MS/s. This is usually not the bottleneck (with a good Computer), so I tested the USRP sink directly plumbed to one of these sources.

For the second problem, I first made sure I had a working setup with UHD. I validated this with the benchmark. To get no underflows with UHD, I had to use the DPDK and all the tips from the knowledgebase.

As you say, there may be some suboptimal default configuration of the USRP sink block:

For example, I wondered why the GNU Radio USRP sink block options did not include the --priority "high" and --multi_streamer option from the UHD script when using a source and sink in the same flowgraph.

I also wondered what might be the best buffer size of the blocks as it had some performance implications.

In addition, it was not possible to have two flow graphs, one with a USRP sink, one with the source, to use the DPDK in parallel.

All in all, I would conclude that GNU Radio in its current state cannot deliver high bandwidth rates (above 61.44 MS/s) for the X410 or X440.

BR,
Sebastian