Increasing spp and mtu values in rfnoc_rx_to_file example #rfnoc

vahidrezaee commented 1 month ago

Issue Description

I have an X410 usrp device and I want to run the rfnoc_rx_to_file example, I have logged the value of spp and mtu in radio and DDC blocks, however, I want to change the value of spp in the radio block it never goes above 364, I have investigated and I found this line in const size_t spp_from_mtu = (_mtu - _hdr_len) / _convert_info.bytes_per_otw_item; it seems that value of mtu dictate the value of spp.

The Ettus Research knowledge base explains that the "MTU (maximum transmission unit) is controlled by the RFNoC framework itself. This framework determines the MTU based on buffer sizes between blocks, and that value is read from an FPGA register. Because of this, block properties cannot be used to directly change the MTU."

Even though I tried increasing the buffer size of the stream endpoint in the FPGA image core .yml file and rebuilt it, there was no impact on the MTU or spp values.

Setup Details

there is my question

1_ how to increase the value of spp?

2_ Is it possible to increase the value of mtu ? and how?

3_ Is it possible to increase the value of atomic item size? and how?

4_is it possible to have an FFT block with size of length=1024 or higher?

Actual Behaviour

the value of spp never goes higher than 364, the value of mtu is 1472

Steps to reproduce the problem

load the default FPGA image on the device and run the rfnoc_rx_to_file example ./rfnoc_rx_to_file --freq 443e6 --rate 5e6 --gain 10 --spp 380

Additional Information

there is my log of running rfnoc_rx_to _file example $ ./rfnoc_rx_to_file --freq 443e6 --rate 5e6 --gain 10 --spp 380


Creating the RFNoC graph with args: 

[INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; UHD_4.4.0.0-33-g4a77791c

[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.10.2,type=x4xx,product=x410,serial=32571D3,name=ni-x4xx-32571D3,fpga=X4_200,claimed=False,addr=192.168.10.2

[INFO] [MPM.PeriphManager] init() called with device args `fpga=X4_200,mgmt_addr=192.168.10.2,name=ni-x4xx-32571D3,product=x410,clock_source=internal,time_source=internal'.

[INFO] [0/FFT#0] Setting default MTU forward policy.

Using radio 0, channel 0

Requesting RX Freq: 443 MHz...

Actual RX Freq: 443 MHz...

Requesting RX Gain: 10 dB...

Actual RX Gain: 10 dB...

Waiting for "lo_locked": ++++++++++ locked.

Requesting samples per packet of: 380

Actual samples per packet = 380

Using streamer args: 

BEFORE graph commit

radio input mtu is : 8192

radio output mtu is : 8192

ddc input mtu is : 8192

ddc output mtu is : 8192

streamer max num samps : 18446744073709551615

radio spp is : 380

radio rate is : 2.4576e+08

ddc rate is : 1

ddc rate is : 1

Active connections:

* 0/Radio#0:0==>0/DDC#0:0

* 0/DDC#0:0-->RxStreamer#0:0

AFTER graph commit 

radio rate is : 2.4576e+08

radio input mtu is : 8192

radio output mtu is : 1472

ddc input mtu is : 1472

ddc output mtu is : 1472

streamer max num samps : 360

radio spp is : 364

 CHANGE spp of radio again

Requesting samples per packet of: 380

Actual samples per packet = 364

AFTER CHANGE 

radio rate is : 2.4576e+08

radio input mtu is : 8192

radio output mtu is : 1472

ddc input mtu is : 1472

ddc output mtu is : 1472

streamer max num samps : 360

radio spp is : 364

Requesting RX Rate: 5 Msps...

Setting rate on DDC block!

[WARNING] [0/DDC#0] The requested decimation is odd; the user should expect passband CIC rolloff.

Select an even decimation to ensure that a halfband filter is enabled.

Decimations factorable by 4 will enable 2 halfbands, those factorable by 8 will enable 3 halfbands.

decimation = dsp_rate/samp_rate -> 49

Actual RX Rate: 5.01551 Msps...

Press Ctrl + C to stop streaming...

[WARNING] [0/DDC#0] The requested decimation is odd; the user should expect passband CIC rolloff.

Select an even decimation to ensure that a halfband filter is enabled.

Decimations factorable by 4 will enable 2 halfbands, those factorable by 8 will enable 3 halfbands.

decimation = dsp_rate/samp_rate -> 49

Issuing stream cmd

NI-LAm commented 1 month ago

The most likely case is that your ethernet connection is the one that restricts the MTU. Try to enable jumbo frame support on your host ethernet configuration, e.g. on ubuntu

sudo ip link set <your_eth_if> mtu 9000

Regards

Lars

vahidrezaee commented 1 month ago

Thanks for the insightful comments and suggestions on the original issue! The information about the RFNoC framework managing MTU and exploring alternative approaches was very helpful.

There's an additional detail I'd like to share: I'm running Ubuntu 20.04 inside a VMware environment. While the discussion focused on modifying MTU within the Ettus Research framework, I discovered that for the changes to take full effect, I also need to adjust the MTU of the QSFP adapter on the host machine (which is running Windows).

This finding might be relevant for others using virtual machines with Ettus Research USRPs. It highlights the importance of considering the entire network path, including the host machine's settings, when troubleshooting MTU-related issues

EttusResearch / uhd