Hi Zack, I don't know the answers to your issues, but I'm wondering if you can just use benchmark_rate rather than your custom code to evaluate performance. If benchmark_rate can't run at the rate you want, it is unlikely that your custom code will succeed. Rob
On Mon, Mar 11, 2024 at 2:35 PM <zackk...@utexas.edu> wrote: > Hello! > > I am having trouble using a USRP X410 to capture some high-rate data. I > would appreciate any insight or help. Below is a diagram of how our x410 is > connected to our host device. > > *---------------------* *---------------------* > > | | NIC QSFP Port 0 | | QSFP28 Port 1 | | > > | | ens1f0np0 <>---------------<> sfp1 | | > > | | 192.168.20.1 | | 192.168.20.2 | | > > | |-----------------| |-----------------| | > > | H | NIC QSFP Port 1 | | QSFP28 Port 0 | X | > > | O | ens1f1np1 <>---------------<> sfp0 | 4 | > > | S | 192.168.10.1 | | 192.168.10.2 | 1 | > > | T |-----------------| *-----------* |-----------------| 0 | > > | | Ethernet Port 1 | |Router | | Ethernet Port | | > > | | eno8403 <>-|192.168.1.1|-<> eth0 | | > > | | 192.168.1.20 | | | | 192.168.1.19 | | > > *---------------------* *-----------* *---------------------* > > When I run $ uhd_find_devices > > [INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; DPDK_19.11; > UHD_4.6.0.HEAD-0-g50fa3baa > > -------------------------------------------------- > > -- UHD Device 0 > > -------------------------------------------------- > > Device Address: > > serial: [serial number] > > addr: 192.168.20.2 > > claimed: False > > fpga: CG_400 > > mgmt_addr: 192.168.1.19 > > mgmt_addr: 192.168.10.2 > > mgmt_addr: 192.168.20.2 > > name: [name] > > product: x410 > > type: x4xx > > I am using two images for the FPGA, each of which has different > capabilities: > > - UC_200, which on the wiki lists Port 0 as "unused" and can achieve up to > 250 Msps per channel. > > - CG_400, which lists both ports on the wiki as "100 GbE" and can achieve > up to 500 Msps per channel. > > I am using UHD's C++ API to instruct the x410. My capture process tries to > call "recv" as soon as possible without waiting to write the previous > buffer to a file. The psudocode is as follows: > > - Initialize "circular" buffer of arrays. Each array is "spb" samples > long, and there are N such buffers. > > - Start a "writing" thread that writes data from a queue to a file. > > - Set the number of samples I need (nsamps_requested), set the current > number of samples to 0 (nsamps), > > - set the current buffer index to 0 (buff_idx) > > - set up rx_streamer to start 0.1 seconds in the future and issue > STREAM_MODE_START_CONTINUOUS command. > > While (nsamps <= nsamps_requested || not_error) > > -Get a pointer to the buffer at buff_idx > > -num_rx_samps <- recv(buffer...) > > -check metadata returned object > > -add the buffer to the queue, increment the buffer index > > - stop streaming > > When I use the process above, I can get very long captures using the > UC_200 image, with 250 Msps, and by parsing the args > "addr=192.168.20.2,mgmt_addr=192.168.1.19" when creating the multiusrp > pointer. > > When I switch to the CG_400 image, I can barely record a few seconds worth > of data. I parse the args > "addr=192.168.10.2,second_addr=192.168.20.2,mgmt_addr=192.168.1.19". I > changed the logger level to get a better idea of what might be going on, > below are some outputs for spb at 5000: > > [DEBUG] [RFNOC::MGMT] Established a route from EPID=4 (SW) to EPID=3 > > [DEBUG] [RFNOC::MGMT] Throttling stream endpoint to 100% (0x0) > > [DEBUG] [RFNOC::MGMT] Initiated RX stream setup for EPID=3 > > [DEBUG] [RFNOC::MGMT] Finished RX stream setup for EPID=3 > > [DEBUG] [0/Radio#0] spp value 2032 exceeds MTU of 8016! Coercing to 1988 > > .... > > [DEBUG] [RxStreamer#0] Received overrun message on port 0 > > After the last logger message, I catc this in my "check metadata returned > object" step and stop the loop. > > When this happens, I sometimes get 0 samples back, and sometimes get less > than the samples per buffer I feed the recv command. I also found that > while waiting for the issued command to take effect, instead of adding > empty buffers to my queue, I check for ERROR_CODE_TIMEOUT and just continue > the while loop. > > I would imagine if I can handle half the rate at 250 Msps for minutes of > continuous capture, going to 500 Msps I could get more than a couple > seconds. Is this because the UC_200 image has 4GiB of DRAM and the CG_400 > doesn't list any on the wiki? Is there something better I can be doing > about the spb (I tried larger and smaller, with some luck around 50000 > spb)? Am I properly configuring the x410 to use both QSFP28 ports for the > CG_400 image? > > Thanks! > > Zack > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
