benchmark_rate uses the multi_usrp object which will configure an RFNoC graph that looks like "Radio->DDC->Host" for each rx channel. So, this doesn't include the FFT or phosphor blocks from your gnuradio flowgraph. So, I guess the problem still could exist in either gr-ettus or uhd with respect to those two blocks.
Rob On Fri, Feb 1, 2019 at 1:53 PM Jason Matusiak <ja...@gardettoengineering.com> wrote: > I needed to make some mods to your command, but it seems to have worked. > Not sure why it tried to list tx channels since I didn't request any, but > it doesn't seemed to have gotten in the way. I am guessing this points > towards your gr-ettus concerns. > > jmatusiak@sdr-server-04:/opt/gnuradio/rfnoc/src/uhd/host/build/examples$ > ./benchmark_rate --args="addr0=192.168.42.2,addr1=192.168.52.2" > --ref=internal --pps=internal --rx_channels="0,1,2,3,4,5,6,7" --rx_rate=25e6 > [INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-36); > Boost_105300; UHD_3.14.0.0-85-g33233e5c > [WARNING] [UHD] Unable to set the thread priority. Performance may be > negatively affected. > Please see the general application notes in the manual for instructions. > EnvironmentError: OSError: error in pthread_setschedparam > > [00:00:00.000022] Creating the usrp device with: > addr0=192.168.42.2,addr1=192.168.52.2... > [INFO] [X300] X300 initialization sequence... > [INFO] [X300] Maximum frame size: 7972 bytes. > [WARNING] [X300] For the 192.168.42.2 connection, UHD recommends a receive > frame size of at least 8000 for best > performance, but your configuration will only allow 7972.This may > negatively impact your maximum achievable sample rate. > Check the MTU on the interface and/or the recv_frame_size argument. > [INFO] [X300] Maximum frame size: 7972 bytes. > [WARNING] [X300] For the 192.168.52.2 connection, UHD recommends a receive > frame size of at least 8000 for best > performance, but your configuration will only allow 7972.This may > negatively impact your maximum achievable sample rate. > Check the MTU on the interface and/or the recv_frame_size argument. > [INFO] [X300] Radio 1x clock: 200 MHz > [INFO] [X300] Radio 1x clock: 200 MHz > [INFO] [GPS] Found an internal GPSDO: LC_XO, Firmware Rev 0.929a > [INFO] [GPS] Found an internal GPSDO: LC_XO, Firmware Rev 0.929a > [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: > 0xF1F0D00000000000) > [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1302 MB/s) > [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1316 MB/s) > [INFO] [1/DmaFIFO_0] Initializing block control (NOC ID: > 0xF1F0D00000000000) > [INFO] [1/DmaFIFO_0] BIST passed (Throughput: 1305 MB/s) > [INFO] [1/DmaFIFO_0] BIST passed (Throughput: 1314 MB/s) > [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000000001) > [INFO] [1/Radio_0] Initializing block control (NOC ID: 0x12AD100000000001) > [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD100000000001) > [INFO] [1/Radio_1] Initializing block control (NOC ID: 0x12AD100000000001) > [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000000) > [INFO] [1/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000000) > [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0000000000000) > [INFO] [1/DDC_1] Initializing block control (NOC ID: 0xDDC0000000000000) > [INFO] [0/Window_0] Initializing block control (NOC ID: 0xD053000000000000) > [INFO] [1/Window_0] Initializing block control (NOC ID: 0xD053000000000000) > [INFO] [0/Window_1] Initializing block control (NOC ID: 0xD053000000000000) > [INFO] [1/Window_1] Initializing block control (NOC ID: 0xD053000000000000) > [WARNING] [RFNOC] Can't find a block controller for key FFT, using default > block controller! > [INFO] [0/FFT_0] Initializing block control (NOC ID: 0xFF70000000000000) > [WARNING] [RFNOC] Can't find a block controller for key FFT, using default > block controller! > [INFO] [1/FFT_0] Initializing block control (NOC ID: 0xFF70000000000000) > [WARNING] [RFNOC] Can't find a block controller for key FFT, using default > block controller! > [INFO] [0/FFT_1] Initializing block control (NOC ID: 0xFF70000000000000) > [WARNING] [RFNOC] Can't find a block controller for key FFT, using default > block controller! > [INFO] [1/FFT_1] Initializing block control (NOC ID: 0xFF70000000000000) > [WARNING] [RFNOC] Can't find a block controller for key fosphor, using > default block controller! > [INFO] [0/fosphor_0] Initializing block control (NOC ID: > 0x666F000000000000) > [WARNING] [RFNOC] Can't find a block controller for key fosphor, using > default block controller! > [INFO] [1/fosphor_0] Initializing block control (NOC ID: > 0x666F000000000000) > [WARNING] [RFNOC] Can't find a block controller for key fosphor, using > default block controller! > [INFO] [0/fosphor_1] Initializing block control (NOC ID: > 0x666F000000000000) > [WARNING] [RFNOC] Can't find a block controller for key fosphor, using > default block controller! > [INFO] [1/fosphor_1] Initializing block control (NOC ID: > 0x666F000000000000) > [WARNING] [RFNOC] Can't find a block controller for key FIFO, using > default block controller! > [INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0000000000000) > [WARNING] [RFNOC] Can't find a block controller for key FIFO, using > default block controller! > [INFO] [1/FIFO_0] Initializing block control (NOC ID: 0xF1F0000000000000) > [WARNING] [RFNOC] Can't find a block controller for key FIFO, using > default block controller! > [INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0000000000000) > [WARNING] [RFNOC] Can't find a block controller for key FIFO, using > default block controller! > [INFO] [1/FIFO_1] Initializing block control (NOC ID: 0xF1F0000000000000) > [WARNING] [X300] Cannot update master clock rate! X300 Series does not > allow changing the clock rate during runtime. > [WARNING] [X300] Cannot update master clock rate! X300 Series does not > allow changing the clock rate during runtime. > [WARNING] [RFNOC] [legacy_compat] No DUCs detected. You will only be able > to transmit at the radio frontend rate. > [WARNING] [X300 RADIO] Requesting invalid sampling rate from device: 200 > MHz. Actual rate is: 100 MHz. > [WARNING] [X300 RADIO] Requesting invalid sampling rate from device: 200 > MHz. Actual rate is: 100 MHz. > [WARNING] [X300 RADIO] Requesting invalid sampling rate from device: 200 > MHz. Actual rate is: 100 MHz. > [WARNING] [X300 RADIO] Requesting invalid sampling rate from device: 200 > MHz. Actual rate is: 100 MHz. > Using Device: Multi USRP: > Device: X-Series Device > Mboard 0: X310 > Mboard 1: X310 > RX Channel: 0 > RX DSP: 0 > RX Dboard: A > RX Subdev: TwinRX RX0 > RX Channel: 1 > RX DSP: 1 > RX Dboard: A > RX Subdev: TwinRX RX1 > RX Channel: 2 > RX DSP: 0 > RX Dboard: B > RX Subdev: TwinRX RX0 > RX Channel: 3 > RX DSP: 1 > RX Dboard: B > RX Subdev: TwinRX RX1 > RX Channel: 4 > RX DSP: 0 > RX Dboard: A > RX Subdev: TwinRX RX0 > RX Channel: 5 > RX DSP: 1 > RX Dboard: A > RX Subdev: TwinRX RX1 > RX Channel: 6 > RX DSP: 0 > RX Dboard: B > RX Subdev: TwinRX RX0 > RX Channel: 7 > RX DSP: 1 > RX Dboard: B > RX Subdev: TwinRX RX1 > TX Channel: 0 > TX DSP: 0 > TX Dboard: A > TX Subdev: Unknown (0x0092) - 0 > TX Channel: 1 > TX DSP: 0 > TX Dboard: B > TX Subdev: Unknown (0x0092) - 0 > TX Channel: 2 > TX DSP: 0 > TX Dboard: A > TX Subdev: Unknown (0x0092) - 0 > TX Channel: 3 > TX DSP: 0 > TX Dboard: B > TX Subdev: Unknown (0x0092) - 0 > > [00:00:05.506538] Setting device timestamp to 0... > [INFO] [MULTI_USRP] 1) catch time transition at pps edge > [INFO] [MULTI_USRP] 2) set times next pps (synchronously) > [WARNING] [MULTI_USRP] Detected time deviation between board 1 and board 0. > Board 0 time is 0.000771 seconds. > Board 1 time is 0.000349 seconds. > > [WARNING] [UHD] Unable to set the thread priority. Performance may be > negatively affected. > Please see the general application notes in the manual for instructions. > EnvironmentError: OSError: error in pthread_setschedparam > [00:00:06.656038] Testing receive rate 25.000000 Msps on 8 channels > [00:00:17.357375] Benchmark complete. > > > Benchmark rate summary: > Num received samples: 1989811512 > Num dropped samples: 0 > Num overruns detected: 0 > Num transmitted samples: 0 > Num sequence errors (Tx): 0 > Num sequence errors (Rx): 0 > Num underruns detected: 0 > Num late commands: 0 > Num timeouts (Tx): 0 > Num timeouts (Rx): 0 > > > Done! > > > ------------------------------ > *From:* Rob Kossler <rkoss...@nd.edu> > *Sent:* Friday, February 1, 2019 1:43 PM > *To:* Jason Matusiak > *Cc:* Ettus Mail List > *Subject:* Re: [USRP-users] two X310s in one RFNoC flowgraph > > I don't know for sure, but it might be possible to try: > benchmark_rate --args="addr0=...,addr1=..." --ref=external --sync=external > --rx_channels="0,1,2,3,4,5,6,7" --rx_rate=25e6 > > If this worked, it might show that the problem is in gr-ettus. But, you > might need to test the concept first using non-twinrx. > Rob > > On Fri, Feb 1, 2019 at 1:36 PM Jason Matusiak < > ja...@gardettoengineering.com> wrote: > > I'll check if fosphor is the issue, but it isn't for my non-twinrx test. > I currently have two X310s, dual receive, so 4 total receives, to a single > host. I had to much with settings to get it to work, but it certainly > isn't an issue in that setup. > > I just double-checked and it isn't the fosphor block. I did notice that > every once in a while it actually seems to make connection (when I reduce > my throughput tremendously), but I don't see data. Without changing > settings, I would say it doesn't error out about 1/10 times. So I think > there is some sort of issue where it assigns IP addresses to the two > devices, and then there is a race condition with which one responds > first.... > > ------------------------------ > *From:* Rob Kossler <rkoss...@nd.edu> > *Sent:* Friday, February 1, 2019 1:28 PM > *To:* Jason Matusiak > *Cc:* Ettus Mail List > *Subject:* Re: [USRP-users] two X310s in one RFNoC flowgraph > > If you use 2 X310 with non-TwinRx daughterboards, it can work with the > same flowgraph (including the fosphor block)? I ask because I am > wondering if there could be a bug in the fosphor block's handling of device > number (either gr-ettus or uhd). > Rob > > On Fri, Feb 1, 2019 at 1:19 PM Jason Matusiak < > ja...@gardettoengineering.com> wrote: > > When I run my flowgraph with the addresses setup that worked before > twinrx, it starts to set everything up and seems to be talking to both ip > addresses. Then it craps out here: > > [WARNING] [RFNOC] Assuming max packet size for 0/DDC_0 > [WARNING] [RFNOC] Assuming max packet size for 0/DDC_1 > [WARNING] [RFNOC] Assuming max packet size for 1/DDC_1 > [WARNING] [RFNOC] Assuming max packet size for 1/DDC_0 > Traceback (most recent call last): > File "/opt/gnuradio/rfnoc/src/gr-ettus/examples/rfnoc/rfnoc_fosphor.py", > line 644, in <module> > main() > File "/opt/gnuradio/rfnoc/src/gr-ettus/examples/rfnoc/rfnoc_fosphor.py", > line 632, in main > tb = top_block_cls() > File "/opt/gnuradio/rfnoc/src/gr-ettus/examples/rfnoc/rfnoc_fosphor.py", > line 475, in __init__ > self.device3.connect(self.uhd_rfnoc_streamer_fft_0_0_0.get_block_id(), > 0, self.uhd_rfnoc_streamer_fosphor_1.get_block_id(), 0) > File > "/opt/gnuradio/rfnoc/lib64/python2.7/site-packages/ettus/ettus_swig.py", > line 1264, in connect > return _ettus_swig.device3_sptr_connect(self, *args) > RuntimeError: RuntimeError: On node 1/fosphor_1, input port 0 is already > connected. > > >>> Done > > That error at the end is usually what you see when you try to use a single > block twice without setting up the block select value. I have checked > things about 50 times, and I have everything setup right as device 1 and 2, > and the blocks (I started with a working flowgraph for non TwinRX X310s), > but I keep getting that error. > > If feels like there is a UHD issue that when it is trying to setup which > block goes with which device, it thinks that there is only one device.... > > > ------------------------------ > *From:* Rob Kossler <rkoss...@nd.edu> > *Sent:* Friday, February 1, 2019 1:14 PM > *To:* Jason Matusiak > *Cc:* Ettus Mail List > *Subject:* Re: [USRP-users] two X310s in one RFNoC flowgraph > > How is it failing? > > On Fri, Feb 1, 2019 at 1:11 PM Jason Matusiak < > ja...@gardettoengineering.com> wrote: > > Yep, works fine. When I am doing it in companion, it also reports info on > both boxes while setting it up, but it feels like it only tries to talk to > the first one it sees. > > ------------------------------ > *From:* Rob Kossler <rkoss...@nd.edu> > *Sent:* Friday, February 1, 2019 1:08 PM > *To:* Jason Matusiak > *Cc:* Ettus Mail List > *Subject:* Re: [USRP-users] two X310s in one RFNoC flowgraph > > Perhaps run uhd_usrp_probe with > --args="addr0=192.168.30.2,addr1=192.168.40.2" and make sure that it is > happy and shows you all of the blocks. > Rob > > On Fri, Feb 1, 2019 at 12:17 PM Jason Matusiak < > ja...@gardettoengineering.com> wrote: > > Upon further review, even though this worked, it doesn't seem to work for > dual X310s with TwinRXs in it. Anyone have any multi-usrp advice with that > (since I pretty much no experience with TwinRX)? I figure there might be a > clue that there could help me with the rfnoc side of things. > > > ------------------------------ > *From:* Jason Matusiak > *Sent:* Friday, February 1, 2019 9:43 AM > *To:* Rob Kossler > *Cc:* Ettus Mail List > *Subject:* Re: [USRP-users] two X310s in one RFNoC flowgraph > > > Rob, > > > I just figured it out (I found lots of people asking the question, but no > answers, so hopefully this can help someone else). > > > 1st - Set the "device select" option to 0 and 1 for the different X310s > (usually you leave it at -1, but change the block select, but here we need > to mod it). > > 2nd - you need a single Device3 like usual > > 3rd - under the Device Arguments block, add in your two IP addresses using > the key of addr0 and addr1 like this: "addr0=192.168.30.2, > addr1=192.168.40.2" (I tried it both with and without the quotes and it > works fine either way), > > > Now, Device 0 will get associated with addr0, and device 1 will get > associates with addr1. > > > I hope that makes sense and helps someone. > > ------------------------------ > *From:* Rob Kossler <rkoss...@nd.edu> > *Sent:* Friday, February 1, 2019 9:23 AM > *To:* Jason Matusiak > *Cc:* Ettus Mail List > *Subject:* Re: [USRP-users] two X310s in one RFNoC flowgraph > > Hi Jason, > Given that under the hood, the stock multi_usrp (along with legacy_compat) > implements an RFNoC graph, it must be possible. I have run multiple X310s > with the stock multi_usrp. I have looked at legacy_compat pretty > thoroughly and it keeps track of blocks as a function of device number > (motherboard). If I had a 2nd X310 handy, I would try it with my own > non-stock multi_usrp object, but I don't - sorry. > Rob > > On Fri, Feb 1, 2019 at 8:30 AM Jason Matusiak via USRP-users < > usrp-users@lists.ettus.com> wrote: > > Is it possible to have a single flowgraph that has 2 X310s running RFNoC > in it? I can't seem to figure out a way to make it work, though I think > there must be a way. Both streams would be streaming to the same host > machine for processing. > > > Thanks. > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
