[USRP-users] two X310s in one RFNoC flowgraph

Rob Kossler rkossler at nd.edu
Fri Feb 1 14:19:40 EST 2019


Not sure..

This may be irrelevant, but I noticed that you only have 2 FFT and 2
fosphor blocks per device, whereas the TwinRx has 4 channels since the
Radio and DDC blocks handle 2 channels each.  It seems that you would only
get 4 channels out of two X310/TwinRx  rather than 8.
Rob

On Fri, Feb 1, 2019 at 2:02 PM Jason Matusiak <jason at gardettoengineering.com>
wrote:

> One more piece of information.  If in my device address list in Device3, I
> put my 52.2 ip before the 42.2 ip, it seems to not die like before.  This
> again makes me think that it is grabbing things and randomly assigning
> which device goes to which IP, yet something else has already the IPs, so
> it is a crap-shoot.
>
> ------------------------------
> *From:* Jason Matusiak
> *Sent:* Friday, February 1, 2019 1:53 PM
> *To:* Rob Kossler
> *Cc:* Ettus Mail List
> *Subject:* Re: [USRP-users] two X310s in one RFNoC flowgraph
>
> 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> 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>
> *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> 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>
> *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> 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>
> *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> 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>
> *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> 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
> 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/c6debc59/attachment.html>


More information about the USRP-users mailing list