Looking at this a little closer, I think a comment in device3.hpp (in
uhd/host/include) probably points to the issue. Before 3 different
declarations, the comments include the line:
"note this access is not thread safe if peformed during block enumeration" (it
is misspelled in the comment).
I assume that if it was easy to make it thread safe it would have been done
already, but I think it is biting me now and my quick attempt at working around
it hasn't gone so well as of yet.
________________________________
From: Jason Matusiak
Sent: Monday, February 4, 2019 1:40 PM
To: Rob Kossler
Cc: Ettus Mail List
Subject: Re: [USRP-users] two X310s in one RFNoC flowgraph
I just realized that the order of IP addresses in Device3 matters for boxes
that aren't TwinRX as well. So this isn't a multi_usrp twinrx problem, but a
more generic one.
________________________________
From: Jason Matusiak
Sent: Friday, February 1, 2019 2:02 PM
To: Rob Kossler
Cc: Ettus Mail List
Subject: Re: [USRP-users] two X310s in one RFNoC flowgraph
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@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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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
