[USRP-users] two X310s in one RFNoC flowgraph

Jason Matusiak jason at gardettoengineering.com
Fri Feb 1 13:53:10 EST 2019


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 at 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 <rkossler at 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 <jason at gardettoengineering.com<mailto:jason at 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 <rkossler at nd.edu<mailto:rkossler at 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 <jason at gardettoengineering.com<mailto:jason at 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 <rkossler at nd.edu<mailto:rkossler at 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 <jason at gardettoengineering.com<mailto:jason at 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 <rkossler at nd.edu<mailto:rkossler at 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 <jason at gardettoengineering.com<mailto:jason at 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 <rkossler at nd.edu<mailto:rkossler at 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 at lists.ettus.com<mailto:usrp-users at 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 at lists.ettus.com<mailto:USRP-users at lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20190201/1248a810/attachment.html>


More information about the USRP-users mailing list