Discussion and technical support related to USRP, UHD, RFNoC
View all threadsPerhaps you could provide the terminal log for the commands
"uhd_usrp_probe" and "uhd_image_loader" (including the commands themselves
so we can see the exact command line arguments).
Rob
On Mon, Nov 29, 2021 at 2:13 PM iw1fnw@gmail.com wrote:
That is what I did (with the help of a colleague). It all went fine till
almost the end. I managed to get the x310 working (e.g. answering to the
uhd_usrp_probe command) after programming with Vivado.
But when I try the uhd_image_loader command at the end, I get the error
above (exactly in the same way as explained by Julian in his first post).
So, I am now stuck with the x310 working but just if I do not switch it
off, since the image in ROM is somewhat corrupted.
I’m not sure if the connection is not reliable. The x310 is directly
connected to the PC via two 10G SFP+ cables. Is there a way to test this? I
think there is another x310 in the lab, which I could use to test, but I do
not want to mess up also that one, since it is not mine.
Al
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
This is what I obtain from the two commands. In the image loader command, if I do not specify the image it takes automatically the XG, which is the same I used to program the FPGA with Vivado (2x10G).
abusso@ttclabsdr:~$ uhd_usrp_probe
linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown
-- X300 initialization sequence...
-- Determining maximum frame size... 8000 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1302.6MB/s)
-- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1304.5MB/s)
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
_____________________________________________________
/
| Device: X-Series Device
| _____________________________________________________
| /
| | Mboard: X310
| | revision: 11
| | revision_compat: 7
| | product: 30818
| | mac-addr0: 00:80:2f:30:8e:01
| | mac-addr1: 00:80:2f:30:8e:02
| | gateway: 192.168.10.1
| | ip-addr0: 192.168.10.2
| | subnet0: 255.255.255.0
| | ip-addr1: 192.168.20.2
| | subnet1: 255.255.255.0
| | ip-addr2: 192.168.30.2
| | subnet2: 255.255.255.0
| | ip-addr3: 192.168.40.2
| | subnet3: 255.255.255.0
| | serial: 31D7872
| | name: TTC_X310
| | FW Version: 5.1
| | FPGA Version: 33.0
| | RFNoC capable: Yes
| |
| | Time sources: internal, external, gpsdo
| | Clock sources: internal, external, gpsdo
| | Sensors: ref_locked
| | _____________________________________________________
| | /
| | | RX Dboard: A
| | | ID: UBX-160 v2 (0x007e)
| | | Serial: 31D5853
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: UBX RX
| | | | Antennas: TX/RX, RX2, CAL
| | | | Sensors: lo_locked
| | | | Freq range: 10.000 to 6000.000 MHz
| | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
| | | | Bandwidth range: 160000000.0 to 160000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: ads62p48
| | | | Gain range digital: 0.0 to 6.0 step 0.5 dB
| | _____________________________________________________
| | /
| | | RX Dboard: B
| | | ID: UBX-160 v2 (0x007e)
| | | Serial: 31D5807
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: UBX RX
| | | | Antennas: TX/RX, RX2, CAL
| | | | Sensors: lo_locked
| | | | Freq range: 10.000 to 6000.000 MHz
| | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
| | | | Bandwidth range: 160000000.0 to 160000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: B
| | | | Name: ads62p48
| | | | Gain range digital: 0.0 to 6.0 step 0.5 dB
| | _____________________________________________________
| | /
| | | TX Dboard: A
| | | ID: UBX-160 v2 (0x007d)
| | | Serial: 31D5853
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: UBX TX
| | | | Antennas: TX/RX, CAL
| | | | Sensors: lo_locked
| | | | Freq range: 10.000 to 6000.000 MHz
| | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
| | | | Bandwidth range: 160000000.0 to 160000000.0 step 0.0 Hz
| | | | Connection Type: QI
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: ad9146
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX Dboard: B
| | | ID: UBX-160 v2 (0x007d)
| | | Serial: 31D5807
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: UBX TX
| | | | Antennas: TX/RX, CAL
| | | | Sensors: lo_locked
| | | | Freq range: 10.000 to 6000.000 MHz
| | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
| | | | Bandwidth range: 160000000.0 to 160000000.0 step 0.0 Hz
| | | | Connection Type: QI
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: B
| | | | Name: ad9146
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | RFNoC blocks on this device:
| | |
| | | * DmaFIFO_0
| | | * Radio_0
| | | * Radio_1
| | | * DDC_0
| | | * DDC_1
| | | * DUC_0
| | | * DUC_1
abusso@ttclabsdr:~$ uhd_image_loader --args "type=x300,addr=192.168.30.2"
linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown
Unit: USRP X310 (31D7872, 192.168.30.2)
FPGA Image: /usr/share/uhd/images/usrp_x310_fpga_XG.bit
failed.
Error: RuntimeError: Device reported an error during initialization.
abusso@ttclabsdr:~$
On 2021-12-03 07:47, iw1fnw@gmail.com wrote:
This is what I obtain from the two commands. In the image loader
command, if I do not specify the image it takes automatically the XG,
which is the same I used to program the FPGA with Vivado (2x10G).
|abusso@ttclabsdr:~$ uhd_usrp_probe|
|linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown|
|-- X300 initialization sequence...|
|-- Determining maximum frame size... 8000 bytes.|
|-- Setup basic communication...|
|-- Loading values from EEPROM...|
|-- Setup RF frontend clocking...|
|-- Radio 1x clock:200|
|-- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1302.6MB/s)|
|-- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1304.5MB/s)|
|-- [RFNoC Radio] Performing register loopback test... pass|
|-- [RFNoC Radio] Performing register loopback test... pass|
|-- [RFNoC Radio] Performing register loopback test... pass|
|-- [RFNoC Radio] Performing register loopback test... pass|
|-- Performing timer loopback test... pass|
|-- Performing timer loopback test... pass|
|_____________________________________________________|
|/|
|| Device: X-Series Device|
|| _____________________________________________________|
|| /|
|| | Mboard: X310|
|| | revision: 11|
|| | revision_compat: 7|
|| | product: 30818|
|| | mac-addr0: 00:80:2f:30:8e:01|
|| | mac-addr1: 00:80:2f:30:8e:02|
|| | gateway: 192.168.10.1|
|| | ip-addr0: 192.168.10.2|
|| | subnet0: 255.255.255.0|
|| | ip-addr1: 192.168.20.2|
|| | subnet1: 255.255.255.0|
|| | ip-addr2: 192.168.30.2|
|| | subnet2: 255.255.255.0|
|| | ip-addr3: 192.168.40.2|
|| | subnet3: 255.255.255.0|
|| | serial: 31D7872|
|| | name: TTC_X310|
|| | FW Version: 5.1|
|| | FPGA Version: 33.0|
|| | RFNoC capable: Yes|
|| ||
|| | Time sources: internal, external, gpsdo|
|| | Clock sources: internal, external, gpsdo|
|| | Sensors: ref_locked|
|| | _____________________________________________________|
|| | /|
|| | | RX Dboard: A|
|| | | ID: UBX-160 v2 (0x007e)|
|| | | Serial: 31D5853|
|| | | _____________________________________________________|
|| | | /|
|| | | | RX Frontend: 0|
|| | | | Name: UBX RX|
|| | | | Antennas: TX/RX, RX2, CAL|
|| | | | Sensors: lo_locked|
|| | | | Freq range: 10.000 to 6000.000 MHz|
|| | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB|
|| | | | Bandwidth range: 160000000.0 to 160000000.0 step 0.0 Hz|
|| | | | Connection Type: IQ|
|| | | | Uses LO offset: No|
|| | | _____________________________________________________|
|| | | /|
|| | | | RX Codec: A|
|| | | | Name: ads62p48|
|| | | | Gain range digital: 0.0 to 6.0 step 0.5 dB|
|| | _____________________________________________________|
|| | /|
|| | | RX Dboard: B|
|| | | ID: UBX-160 v2 (0x007e)|
|| | | Serial: 31D5807|
|| | | _____________________________________________________|
|| | | /|
|| | | | RX Frontend: 0|
|| | | | Name: UBX RX|
|| | | | Antennas: TX/RX, RX2, CAL|
|| | | | Sensors: lo_locked|
|| | | | Freq range: 10.000 to 6000.000 MHz|
|| | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB|
|| | | | Bandwidth range: 160000000.0 to 160000000.0 step 0.0 Hz|
|| | | | Connection Type: IQ|
|| | | | Uses LO offset: No|
|| | | _____________________________________________________|
|| | | /|
|| | | | RX Codec: B|
|| | | | Name: ads62p48|
|| | | | Gain range digital: 0.0 to 6.0 step 0.5 dB|
|| | _____________________________________________________|
|| | /|
|| | | TX Dboard: A|
|| | | ID: UBX-160 v2 (0x007d)|
|| | | Serial: 31D5853|
|| | | _____________________________________________________|
|| | | /|
|| | | | TX Frontend: 0|
|| | | | Name: UBX TX|
|| | | | Antennas: TX/RX, CAL|
|| | | | Sensors: lo_locked|
|| | | | Freq range: 10.000 to 6000.000 MHz|
|| | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB|
|| | | | Bandwidth range: 160000000.0 to 160000000.0 step 0.0 Hz|
|| | | | Connection Type: QI|
|| | | | Uses LO offset: No|
|| | | _____________________________________________________|
|| | | /|
|| | | | TX Codec: A|
|| | | | Name: ad9146|
|| | | | Gain Elements: None|
|| | _____________________________________________________|
|| | /|
|| | | TX Dboard: B|
|| | | ID: UBX-160 v2 (0x007d)|
|| | | Serial: 31D5807|
|| | | _____________________________________________________|
|| | | /|
|| | | | TX Frontend: 0|
|| | | | Name: UBX TX|
|| | | | Antennas: TX/RX, CAL|
|| | | | Sensors: lo_locked|
|| | | | Freq range: 10.000 to 6000.000 MHz|
|| | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB|
|| | | | Bandwidth range: 160000000.0 to 160000000.0 step 0.0 Hz|
|| | | | Connection Type: QI|
|| | | | Uses LO offset: No|
|| | | _____________________________________________________|
|| | | /|
|| | | | TX Codec: B|
|| | | | Name: ad9146|
|| | | | Gain Elements: None|
|| | _____________________________________________________|
|| | /|
|| | | RFNoC blocks on this device:|
|| | ||
|| | | * DmaFIFO_0|
|| | | * Radio_0|
|| | | * Radio_1|
|| | | * DDC_0|
|| | | * DDC_1|
|| | | * DUC_0|
|| | | * DUC_1|
|abusso@ttclabsdr:~$ uhd_image_loader --args "type=x300,addr=192.168.30.2"|
|linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown|
|Unit: USRP X310 (31D7872, 192.168.30.2)|
|FPGA Image: /usr/share/uhd/images/usrp_x310_fpga_XG.bit|
|failed.|
|Error: RuntimeError: Device reported an error during initialization.|
|abusso@ttclabsdr:~$|
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-leave@lists.ettus.com
What happens if you download fresh images (uhd_images_downloader), and
try this again?
When the device is running, if you ping it, do you get any errors
(packet drops)?
I can try re-programming with new images (if not already done) starting from Vivado. Is this what you mean?
I tried a flood ping. With up to 6000 bytes packet all is fine. With 7000 I start loosing a bit. With 8000 it loose 50%. I’m not sure if this is normal with such long packets.
abusso@ttclabsdr:~$ sudo ping -s 6000 192.168.30.2 -f
PING 192.168.30.2 (192.168.30.2) 6000(6028) bytes of data.
.
--- 192.168.30.2 ping statistics ---
147 packets transmitted, 146 received, 0% packet loss, time 2875ms
rtt min/avg/max/mdev = 19.729/25.174/27.233/1.240 ms, pipe 2, ipg/ewma 19.697/24.942 ms
abusso@ttclabsdr:~$ sudo ping -s 7000 192.168.30.2 -f
PING 192.168.30.2 (192.168.30.2) 7000(7028) bytes of data.
.....................
--- 192.168.30.2 ping statistics ---
119 packets transmitted, 98 received, 17% packet loss, time 2235ms
rtt min/avg/max/mdev = 22.885/101.313/137.328/24.301 ms, pipe 8, ipg/ewma 18.943/108.385 ms
abusso@ttclabsdr:~$ sudo ping -s 8000 192.168.30.2 -f
PING 192.168.30.2 (192.168.30.2) 8000(8028) bytes of data.
.....................................................................
--- 192.168.30.2 ping statistics ---
138 packets transmitted, 69 received, 50% packet loss, time 1799ms
rtt min/avg/max/mdev = 26.077/111.479/130.336/20.520 ms, pipe 10, ipg/ewma 13.138/116.295 ms
On 2021-12-03 09:14, iw1fnw@gmail.com wrote:
I can try re-programming with new images (if not already done)
starting from Vivado. Is this what you mean?
I tried a flood ping. With up to 6000 bytes packet all is fine. With
7000 I start loosing a bit. With 8000 it loose 50%. I’m not sure if
this is normal with such long packets.
|abusso@ttclabsdr:~$ sudo ping -s 6000 192.168.30.2 -f PING
192.168.30.2 (192.168.30.2) 6000(6028) bytes of data. . ---
192.168.30.2 ping statistics --- 147 packets transmitted, 146
received, 0% packet loss, time 2875ms rtt min/avg/max/mdev =
19.729/25.174/27.233/1.240 ms, pipe 2, ipg/ewma 19.697/24.942 ms
abusso@ttclabsdr:~$ sudo ping -s 7000 192.168.30.2 -f PING
192.168.30.2 (192.168.30.2) 7000(7028) bytes of data.
..................... --- 192.168.30.2 ping statistics --- 119 packets
transmitted, 98 received, 17% packet loss, time 2235ms rtt
min/avg/max/mdev = 22.885/101.313/137.328/24.301 ms, pipe 8, ipg/ewma
18.943/108.385 ms abusso@ttclabsdr:~$ sudo ping -s 8000 192.168.30.2
-f PING 192.168.30.2 (192.168.30.2) 8000(8028) bytes of data.
.....................................................................
--- 192.168.30.2 ping statistics --- 138 packets transmitted, 69
received, 50% packet loss, time 1799ms rtt min/avg/max/mdev =
26.077/111.479/130.336/20.520 ms, pipe 10, ipg/ewma 13.138/116.295 ms |
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-leave@lists.ettus.com
What type of NIC do you have? What is the MTU setting? If you turn the
MTU down to 1500 and re-try your image load, what happens?
I don't know exactly when, but Ettus changed from using XGS and HGS images
to XG and HG. I think this was in between 3.9 and 3.10 so maybe you are OK
with the XG image. But, I would recommend using the "--fpga-path" command
line argument to specify exactly which image you want. My guess is that
when you use Vivado to download an image and things "work", you are
selecting an exact FPGA file in the Vivado GUI. What happens if you select
this example same file using the "--fpga-path" argument to the
uhd_image_loader program?
On Fri, Dec 3, 2021 at 9:15 AM iw1fnw@gmail.com wrote:
I can try re-programming with new images (if not already done) starting
from Vivado. Is this what you mean?
I tried a flood ping. With up to 6000 bytes packet all is fine. With 7000
I start loosing a bit. With 8000 it loose 50%. I’m not sure if this is
normal with such long packets.
abusso@ttclabsdr:~$ sudo ping -s 6000 192.168.30.2 -f
PING 192.168.30.2 (192.168.30.2) 6000(6028) bytes of data.
.
--- 192.168.30.2 ping statistics ---
147 packets transmitted, 146 received, 0% packet loss, time 2875ms
rtt min/avg/max/mdev = 19.729/25.174/27.233/1.240 ms, pipe 2, ipg/ewma 19.697/24.942 ms
abusso@ttclabsdr:~$ sudo ping -s 7000 192.168.30.2 -f
PING 192.168.30.2 (192.168.30.2) 7000(7028) bytes of data.
.....................
--- 192.168.30.2 ping statistics ---
119 packets transmitted, 98 received, 17% packet loss, time 2235ms
rtt min/avg/max/mdev = 22.885/101.313/137.328/24.301 ms, pipe 8, ipg/ewma 18.943/108.385 ms
abusso@ttclabsdr:~$ sudo ping -s 8000 192.168.30.2 -f
PING 192.168.30.2 (192.168.30.2) 8000(8028) bytes of data.
.....................................................................
--- 192.168.30.2 ping statistics ---
138 packets transmitted, 69 received, 50% packet loss, time 1799ms
rtt min/avg/max/mdev = 26.077/111.479/130.336/20.520 ms, pipe 10, ipg/ewma 13.138/116.295 ms
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
The NIC is an Intel X710 Dual Port 10Gb Direct Attach, SFP+,PCIe. MTU is now 9000. I tried now with 1500, but still same error. I still have to check with new image, if any.
abusso@ttclabsdr:~$ ifconfig
eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.181.165.152 netmask 255.255.252.0 broadcast 10.181.167.255
inet6 fe80::a6bb:6dff:feae:de8 prefixlen 64 scopeid 0x20<link>
ether a4:bb:6d:ae:0d:e8 txqueuelen 1000 (Ethernet)
RX packets 543759 bytes 60330968 (60.3 MB)
RX errors 0 dropped 8713 overruns 0 frame 0
TX packets 24251 bytes 13359677 (13.3 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 16 memory 0x92f00000-92f20000
enp4s0f0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.30.1 netmask 255.255.255.0 broadcast 192.168.30.255
inet6 fe80::faf2:1eff:fe98:e70 prefixlen 64 scopeid 0x20<link>
ether f8:f2:1e:98:0e:70 txqueuelen 1000 (Ethernet)
RX packets 2493 bytes 3406398 (3.4 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2662 bytes 4716866 (4.7 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp4s0f1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.40.1 netmask 255.255.255.0 broadcast 192.168.40.255
inet6 fe80::faf2:1eff:fe98:e71 prefixlen 64 scopeid 0x20<link>
ether f8:f2:1e:98:0e:71 txqueuelen 1000 (Ethernet)
RX packets 305761 bytes 76146924 (76.1 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 24113 bytes 38423211 (38.4 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enx0050b661c3db: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.100.1 netmask 255.255.255.0 broadcast 192.168.100.255
inet6 fe80::250:b6ff:fe61:c3db prefixlen 64 scopeid 0x20<link>
ether 00:50:b6:61:c3:db txqueuelen 1000 (Ethernet)
RX packets 8896 bytes 585296 (585.2 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 310 bytes 38402 (38.4 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 7296 bytes 23262505 (23.2 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 7296 bytes 23262505 (23.2 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
abusso@ttclabsdr:~$ uhd_image_loader --args "type=x300,addr=192.168.30.2"
linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown
Unit: USRP X310 (31D7872, 192.168.30.2)
FPGA Image: /usr/share/uhd/images/usrp_x310_fpga_XG.bit
failed.
Error: RuntimeError: Device reported an error during initialization.
abusso@ttclabsdr:~$
On 2021-12-03 10:02, iw1fnw@gmail.com wrote:
The NIC is an Intel X710 Dual Port 10Gb Direct Attach, SFP+,PCIe. MTU
is now 9000. I tried now with 1500, but still same error. I still have
to check with new image, if any.
My "hunch" is that packets are getting lost or re-ordered during the
FPGA image load over the network connection, which is why I had you
check with different
MTUs.
Have you replaced the cable? SFP+ module? Is this direct or through a
switch?
|abusso@ttclabsdr:~$ ifconfig eno1:
flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet
10.181.165.152 netmask 255.255.252.0 broadcast 10.181.167.255 inet6
fe80::a6bb:6dff:feae:de8 prefixlen 64 scopeid 0x20<link> ether
a4:bb:6d:ae:0d:e8 txqueuelen 1000 (Ethernet) RX packets 543759 bytes
60330968 (60.3 MB) RX errors 0 dropped 8713 overruns 0 frame 0 TX
packets 24251 bytes 13359677 (13.3 MB) TX errors 0 dropped 0 overruns
0 carrier 0 collisions 0 device interrupt 16 memory
0x92f00000-92f20000 enp4s0f0:
flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.30.1
netmask 255.255.255.0 broadcast 192.168.30.255 inet6
fe80::faf2:1eff:fe98:e70 prefixlen 64 scopeid 0x20<link> ether
f8:f2:1e:98:0e:70 txqueuelen 1000 (Ethernet) RX packets 2493 bytes
3406398 (3.4 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets
2662 bytes 4716866 (4.7 MB) TX errors 0 dropped 0 overruns 0 carrier 0
collisions 0 enp4s0f1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu
1500 inet 192.168.40.1 netmask 255.255.255.0 broadcast 192.168.40.255
inet6 fe80::faf2:1eff:fe98:e71 prefixlen 64 scopeid 0x20<link> ether
f8:f2:1e:98:0e:71 txqueuelen 1000 (Ethernet) RX packets 305761 bytes
76146924 (76.1 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets
24113 bytes 38423211 (38.4 MB) TX errors 0 dropped 0 overruns 0
carrier 0 collisions 0 enx0050b661c3db:
flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.100.1
netmask 255.255.255.0 broadcast 192.168.100.255 inet6
fe80::250:b6ff:fe61:c3db prefixlen 64 scopeid 0x20<link> ether
00:50:b6:61:c3:db txqueuelen 1000 (Ethernet) RX packets 8896 bytes
585296 (585.2 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets
310 bytes 38402 (38.4 KB) TX errors 0 dropped 0 overruns 0 carrier 0
collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet
127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback) RX packets 7296 bytes 23262505
(23.2 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 7296
bytes 23262505 (23.2 MB) TX errors 0 dropped 0 overruns 0 carrier 0
collisions 0 abusso@ttclabsdr:~$ uhd_image_loader --args
"type=x300,addr=192.168.30.2" linux; GNU C++ version 7.3.0;
Boost_106501; UHD_003.010.003.000-0-unknown Unit: USRP X310 (31D7872,
192.168.30.2) FPGA Image: /usr/share/uhd/images/usrp_x310_fpga_XG.bit
failed. Error: RuntimeError: Device reported an error during
initialization. abusso@ttclabsdr:~$|
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-leave@lists.ettus.com
I did some more experiments, but without results…
Just to answer your last, the USRP is connected directly to the NIC (no switches).
abusso@ttclabsdr:~$ sudo ethtool enp4s0f0
Settings for enp4s0f0:
Supported ports: [ FIBRE ]
Supported link modes: 10000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: No
Supported FEC modes: Not reported
Advertised link modes: 10000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: 10000Mb/s
Duplex: Full
Port: Direct Attach Copper
PHYAD: 0
Transceiver: internal
Auto-negotiation: off
Supports Wake-on: g
Wake-on: g
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
Since there are two 10GBit connections, I tried the programming using one or the other, but result is the same. So, I do not think it is a problem of cable or SFP+ adapter.
I checked with wireshark what is going on, and the result is that there is an exchange of 72 UDP packets of short length (16 bytes) from PC to USRP, each followed by a reply of 16 bytes, and the communication terminates with a longer one from PC (272 bytes) followed by 4 bytes reply from USRP. So, it seems not much data is transferred and the real image transfer never starts.
The packets are not all the same, so something seems going on, but I have the impression that the last one creates some problems. For the first 72, the answer is quite immediate (20-30us), but the last reply from USRP takes almost 1 second.
If needed, I can attach the wireshark extrack.
On 2021-12-08 03:25, iw1fnw@gmail.com wrote:
I did some more experiments, but without results…
Just to answer your last, the USRP is connected directly to the NIC
(no switches).
|abusso@ttclabsdr:~$ sudo ethtool enp4s0f0 Settings for enp4s0f0:
Supported ports: [ FIBRE ] Supported link modes: 10000baseT/Full
Supported pause frame use: Symmetric Receive-only Supports
auto-negotiation: No Supported FEC modes: Not reported Advertised link
modes: 10000baseT/Full Advertised pause frame use: No Advertised
auto-negotiation: No Advertised FEC modes: Not reported Speed:
10000Mb/s Duplex: Full Port: Direct Attach Copper PHYAD: 0
Transceiver: internal Auto-negotiation: off Supports Wake-on: g
Wake-on: g Current message level: 0x00000007 (7) drv probe link Link
detected: yes |
Since there are two 10GBit connections, I tried the programming using
one or the other, but result is the same. So, I do not think it is a
problem of cable or SFP+ adapter.
I checked with wireshark what is going on, and the result is that
there is an exchange of 72 UDP packets of short length (16 bytes) from
PC to USRP, each followed by a reply of 16 bytes, and the
communication terminates with a longer one from PC (272 bytes)
followed by 4 bytes reply from USRP. So, it seems not much data is
transferred and the real image transfer never starts.
The packets are not all the same, so something seems going on, but I
have the impression that the last one creates some problems. For the
first 72, the answer is quite immediate (20-30us), but the last reply
from USRP takes almost 1 second.
If needed, I can attach the wireshark extrack.
||So, has this device always done this, or it started doing it at some
point recently? How old is the device?