Re: [USRP-users] Fwd: dpdk-test does not work

[akin soysal via USRP-users]

Works beautifully. Thanks, Sam.

Akın

9 Oca 2020 Per 21:54 tarihinde Sam Reiter  şunu yazdı:

> Akin,
>
> I'd recommend you check out our DPDK setup guide - hot off the presses:
>
> https://kb.ettus.com/Getting_Started_with_DPDK_and_UHD
>
> Sam Reiter
> Ettus Research
>
>
> On Wed, Jan 8, 2020 at 10:52 PM akin soysal via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>>
>>
>> -- Forwarded message -
>> Gönderen: akin soysal 
>> Date: 8 Oca 2020 Çar 15:22
>> Subject: dpdk-test does not work
>> To: USRP-users@lists.ettus.com 
>>
>>
>> Dear all,
>>
>> We have a USRP X310 setup and we are trying to make the
>> UHD_3.15.0.0-0-g4e06022c driver work. I have added a file under
>> /etc/uhd/uhd.conf and it is attached to this email.
>>
>> I am not sure about the dpdk-mac and dpdk-ipv4 addresses, what are they
>> used for?
>>
>> I am trying to make the dpdk-test work but I am experiencing problems
>> with setting of ipv4.
>>
>> -
>> sudo ./dpdk_test
>> EAL: Detected 18 lcore(s)
>> EAL: No free hugepages reported in hugepages-1048576kB
>> EAL: Probing VFIO support...
>> EAL: VFIO support initialized
>> EAL: PCI device :05:00.0 on NUMA socket 0
>> EAL:   probe driver: 8086:1533 net_e1000_igb
>> EAL: PCI device :65:00.0 on NUMA socket 0
>> EAL:   probe driver: 8086:1557 net_ixgbe
>> EAL:   using IOMMU type 1 (Type 1)
>> EAL: Ignore mapping IO port bar(2)
>> EAL: Waiting for links to come up...
>> [INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-39);
>> Boost_105800; UHD_3.15.0.0-0-g4e06022c
>> EAL: Init DONE!
>> EAL: Starting I/O threads!
>> terminate called after throwing an instance of 'uhd::assertion_error'
>>   what():  AssertionError: status == 0
>>   in std::string get_ipv4_addr(unsigned int)
>>   at /home/ulak-gnb/workarea-uhd/uhd/host/tests/dpdk_test.cpp:229
>>
>> Aborted
>> -
>>
>> What should be the uhd-dpdk arguments for this to run? It seems like it
>> does not even read the uhd.conf file.
>>
>> I am using DPDK dpdk-stable-17.11.9. I have also programmed my SFP+
>> interface via dpdk-devbind.py as shown below.
>>
>> --
>> sudo ./dpdk-devbind.py -s
>>
>> Network devices using DPDK-compatible driver
>> 
>> :65:00.0 '82599 10 Gigabit Network Connection 1557' drv=vfio-pci
>> unused=ixgbe
>>
>> Network devices using kernel driver
>> ===
>> :04:00.0 'AQC108 NBase-T/IEEE 802.3bz Ethernet Controller [AQtion]
>> d108' if=eth1 drv=atlantic unused=vfio-pci
>> :05:00.0 'I210 Gigabit Network Connection 1533' if=eno1 drv=igb
>> unused=vfio-pci *Active*
>>
>> Other Network devices
>> =
>> 
>>
>> Crypto devices using DPDK-compatible driver
>> ===
>> 
>>
>> Crypto devices using kernel driver
>> ==
>> 
>>
>> Other Crypto devices
>> 
>> 
>>
>> Eventdev devices using DPDK-compatible driver
>> =
>> 
>>
>> Eventdev devices using kernel driver
>> 
>> 
>>
>> Other Eventdev devices
>> ==
>> 
>>
>> Mempool devices using DPDK-compatible driver
>> 
>> 
>>
>> Mempool devices using kernel driver
>> ===
>> 
>>
>> Other Mempool devices
>> =
>> 
>> --
>>
>> Thanks and regards,
>> Akın
>> ___
>> 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

[USRP-users] Fwd: dpdk-test does not work

[akin soysal via USRP-users]

-- Forwarded message -
Gönderen: akin soysal 
Date: 8 Oca 2020 Çar 15:22
Subject: dpdk-test does not work
To: USRP-users@lists.ettus.com 


Dear all,

We have a USRP X310 setup and we are trying to make the
UHD_3.15.0.0-0-g4e06022c driver work. I have added a file under
/etc/uhd/uhd.conf and it is attached to this email.

I am not sure about the dpdk-mac and dpdk-ipv4 addresses, what are they
used for?

I am trying to make the dpdk-test work but I am experiencing problems with
setting of ipv4.

-
sudo ./dpdk_test
EAL: Detected 18 lcore(s)
EAL: No free hugepages reported in hugepages-1048576kB
EAL: Probing VFIO support...
EAL: VFIO support initialized
EAL: PCI device :05:00.0 on NUMA socket 0
EAL:   probe driver: 8086:1533 net_e1000_igb
EAL: PCI device :65:00.0 on NUMA socket 0
EAL:   probe driver: 8086:1557 net_ixgbe
EAL:   using IOMMU type 1 (Type 1)
EAL: Ignore mapping IO port bar(2)
EAL: Waiting for links to come up...
[INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-39);
Boost_105800; UHD_3.15.0.0-0-g4e06022c
EAL: Init DONE!
EAL: Starting I/O threads!
terminate called after throwing an instance of 'uhd::assertion_error'
  what():  AssertionError: status == 0
  in std::string get_ipv4_addr(unsigned int)
  at /home/ulak-gnb/workarea-uhd/uhd/host/tests/dpdk_test.cpp:229

Aborted
-

What should be the uhd-dpdk arguments for this to run? It seems like it
does not even read the uhd.conf file.

I am using DPDK dpdk-stable-17.11.9. I have also programmed my SFP+
interface via dpdk-devbind.py as shown below.

--
sudo ./dpdk-devbind.py -s

Network devices using DPDK-compatible driver

:65:00.0 '82599 10 Gigabit Network Connection 1557' drv=vfio-pci
unused=ixgbe

Network devices using kernel driver
===
:04:00.0 'AQC108 NBase-T/IEEE 802.3bz Ethernet Controller [AQtion]
d108' if=eth1 drv=atlantic unused=vfio-pci
:05:00.0 'I210 Gigabit Network Connection 1533' if=eno1 drv=igb
unused=vfio-pci *Active*

Other Network devices
=


Crypto devices using DPDK-compatible driver
===


Crypto devices using kernel driver
==


Other Crypto devices



Eventdev devices using DPDK-compatible driver
=


Eventdev devices using kernel driver



Other Eventdev devices
==


Mempool devices using DPDK-compatible driver



Mempool devices using kernel driver
===


Other Mempool devices
=

--

Thanks and regards,
Akın
;When present in device args, use_dpdk indicates you want DPDK to take over the 
UDP transports
;The value here represents a config, so you could have another section labeled 
use_dpdk=myconf
;instead and swap between them
[use_dpdk=1]
;dpdk_mtu is the NIC's MTU setting
;This is separate from MPM's maximum packet size
dpdk-mtu=9000
;dpdk_driver is the -d flag for the DPDK EAL. If DPDK doesn't pick up the 
driver for your NIC
;automatically, you may need this argument to point it to the folder where it 
can find the drivers
;Note that DPDK will attempt to load _everything_ in that folder as a driver, 
so you may want to
;create a separate folder with symlinks to the librte_pmd_* and 
librte_mempool_* libraries.
dpdk-driver=/home/ulak-gnb/ulak/dpdk-stable-17.11.9/x86_64-native-linuxapp-gcc/lib/pmds
;dpdk_corelist is the -l flag for the DPDK EAL. See more at the link
; 
https://doc.dpdk.org/guides-18.11/linux_gsg/build_sample_apps.html#running-a-sample-application
dpdk-corelist=5,6
;dpdk_num_mbufs is the total number of packet buffers allocated
;to each direction's packet buffer pool
;This will be multiplied by the number of NICs, but NICs on the same
;CPU socket share a pool.
dpdk-num-mbufs=4095
;dpdk_mbuf_cache_size is the number of buffers to cache for a CPU
;The cache reduces the interaction with the global pool
dpdk-mbuf-cache_size=315

[dpdk-mac=ac:1f:6b:78:5a:09]
;dpdk_lcore selects the lcore that this NIC's driver will run on
;Multiple NICs may occupy one lcore, but the I/O thread will completely
;consume that lcore's CPU. Also, 0 is reserved for the master thread (i.e.
;the initial UHD thread that calls init() for DPDK). Attempting to
;use it as an I/O thread will only result in hanging.
;Note also that by default, the lcore ID will be the same as the CPU ID.
dpdk-io-cpu = 5
;dpdk_ipv4 specifies the IPv4 address, and both the address and
;subnet mask are required (and in this format!). DPDK uses the
;netmask to create a basic routing table. Routing to other networks
;(i.e. via gateways) is not permitted.
dpdk-ipv4 = 10.10.1.5/24
;dpdk_num_desc is the number of descriptors in each DMA ring.
;Must be a power of 2.
;dpdk_num_desc=4096

[dpdk-mac=3c:fd:fe:a2:a9:0a]

Re: [USRP-users] DPDK runtime error

[akin soysal via USRP-users]

Hello all,

Is this problem fixed? If yes, could you please tell how? We have a similar
error, so it would be helpful.

Thanks and regards,
Akın

3 Oca 2020 Cum 23:22 tarihinde Sam Reiter via USRP-users <
usrp-users@lists.ettus.com> şunu yazdı:

> Florian,
>
> DPDK 18.11 is not supported on UHD 3.x. You'll need to use DPDK 17.11.
>
> Sam Reiter
> Ettus Research
>
> On Mon, Dec 23, 2019 at 9:51 AM Florian Kaltenberger via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Dear all,
>>
>> we have finally managed to set up UHD (3.15) with DPDK (18.11) support on
>> our RedHat 7 system (both installed from source) with our N310. I have
>> configured the system as explained here
>> http://files.ettus.com/manual/page_dpdk.html but when calling
>>
>> uhd_usrp_probe --args
>> "use_dpdk=1,mgmt_addr=192.168.12.1,addr=192.168.10.2,second_addr=192.168.20.2,master_clock_rate=122.88e6,type=n3xx"
>>
>> I am getting the following runtime error (all the way at the bottom):
>> [INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-39);
>> Boost_106900; UHD_3.15.0.0-0-g4e06022c
>> EAL: Detected 10 lcore(s)
>> EAL: No free hugepages reported in hugepages-1048576kB
>> EAL: Probing VFIO support...
>> EAL: VFIO support initialized
>> EAL: PCI device :00:19.0 on NUMA socket 0
>> EAL:   probe driver: 8086:153a net_e1000_em
>> EAL: PCI device :01:00.0 on NUMA socket 0
>> EAL:   probe driver: 8086:1572 net_i40e
>> EAL: PCI device :01:00.1 on NUMA socket 0
>> EAL:   probe driver: 8086:1572 net_i40e
>> EAL:   using IOMMU type 1 (Type 1)
>> PMD: Global register is changed during enable FDIR flexible payload
>> PMD: Global register is changed during support QinQ parser
>> PMD: Global register is changed during configure hash input set
>> PMD: Global register is changed during configure fdir mask
>> PMD: Global register is changed during configure hash mask
>> PMD: Global register is changed during support QinQ cloud filter
>> PMD: Global register is changed during support TPID configuration
>> EAL: PCI device :01:00.2 on NUMA socket 0
>> EAL:   probe driver: 8086:1572 net_i40e
>> EAL: PCI device :01:00.3 on NUMA socket 0
>> EAL:   probe driver: 8086:1572 net_i40e
>> PMD: Global register is changed during enable FDIR flexible payload
>> PMD: Global register is changed during support QinQ parser
>> PMD: Global register is changed during configure hash input set
>> PMD: Global register is changed during configure fdir mask
>> PMD: Global register is changed during configure hash mask
>> PMD: Global register is changed during support QinQ cloud filter
>> PMD: Global register is changed during support TPID configuration
>> EAL: Waiting for links to come up...
>> EAL: Init DONE!
>> EAL: Starting I/O threads!
>> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
>> mgmt_addr=192.168.12.1,type=n3xx,product=n310,serial=31641BC,claimed=False,use_dpdk=1,addr=192.168.10.2,second_addr=192.168.20.2,master_clock_rate=122.88e6
>> [INFO] [MPM.PeriphManager] init() called with device args
>> `mgmt_addr=192.168.12.1,product=n310,master_clock_rate=122.88e6,second_addr=192.168.20.2,use_dpdk=1,clock_source=internal,time_source=internal'.
>> EAL: Please set IPv4 address for port 0 before opening socket
>> [ERROR] [MPMD] Failure during block enumeration: AssertionError: _rx_sock
>> != nullptr
>>   in uhd::transport::dpdk_zero_copy_impl::dpdk_zero_copy_impl(const
>> uhd::transport::uhd_dpdk_ctx&, unsigned int, const string&, const string&,
>> const string&, const uhd::transport::zero_copy_xport_params&)
>>
>> I am also copying the output of "dpdk-devbind  --status" which shows that
>> the two interfaces connected to the USRP use the vfio-pci driver for DPDK
>>
>> Network devices using DPDK-compatible driver
>> 
>> :01:00.1 'Ethernet Controller X710 for 10GbE SFP+ 1572' drv=vfio-pci
>> unused=i40e
>> :01:00.3 'Ethernet Controller X710 for 10GbE SFP+ 1572' drv=vfio-pci
>> unused=i40e
>>
>> Network devices using kernel driver
>> ===
>> :00:19.0 'Ethernet Connection I217-LM 153a' if=enp0s25 drv=e1000e
>> unused=vfio-pci *Active*
>> :01:00.0 'Ethernet Controller X710 for 10GbE SFP+ 1572' if=p1p1
>> drv=i40e unused=vfio-pci
>> :01:00.2 'Ethernet Controller X710 for 10GbE SFP+ 1572' if=p1p3
>> drv=i40e unused=vfio-pci
>>
>> What surprises me is that in the output of the uhd_usrp_probe, it does
>> not say it is using the driver for DPDK. any ideas what could be wrong?
>>
>> Florian.
>> --
>> Follow us on Google+ ,
>> LinkedIn , or Twitter
>> !
>> ___
>> 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] dpdk-test does not work

[akin soysal via USRP-users]

Dear all,

We have a USRP X310 setup and we are trying to make the
UHD_3.15.0.0-0-g4e06022c driver work. I have added a file under
/etc/uhd/uhd.conf and it is attached to this email.

I am not sure about the dpdk-mac and dpdk-ipv4 addresses, what are they
used for?

I am trying to make the dpdk-test work but I am experiencing problems with
setting of ipv4.

-
sudo ./dpdk_test
EAL: Detected 18 lcore(s)
EAL: No free hugepages reported in hugepages-1048576kB
EAL: Probing VFIO support...
EAL: VFIO support initialized
EAL: PCI device :05:00.0 on NUMA socket 0
EAL:   probe driver: 8086:1533 net_e1000_igb
EAL: PCI device :65:00.0 on NUMA socket 0
EAL:   probe driver: 8086:1557 net_ixgbe
EAL:   using IOMMU type 1 (Type 1)
EAL: Ignore mapping IO port bar(2)
EAL: Waiting for links to come up...
[INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-39);
Boost_105800; UHD_3.15.0.0-0-g4e06022c
EAL: Init DONE!
EAL: Starting I/O threads!
terminate called after throwing an instance of 'uhd::assertion_error'
  what():  AssertionError: status == 0
  in std::string get_ipv4_addr(unsigned int)
  at /home/ulak-gnb/workarea-uhd/uhd/host/tests/dpdk_test.cpp:229

Aborted
-

What should be the uhd-dpdk arguments for this to run? It seems like it
does not even read the uhd.conf file.

I am using DPDK dpdk-stable-17.11.9. I have also programmed my SFP+
interface via dpdk-devbind.py as shown below.

--
sudo ./dpdk-devbind.py -s

Network devices using DPDK-compatible driver

:65:00.0 '82599 10 Gigabit Network Connection 1557' drv=vfio-pci
unused=ixgbe

Network devices using kernel driver
===
:04:00.0 'AQC108 NBase-T/IEEE 802.3bz Ethernet Controller [AQtion]
d108' if=eth1 drv=atlantic unused=vfio-pci
:05:00.0 'I210 Gigabit Network Connection 1533' if=eno1 drv=igb
unused=vfio-pci *Active*

Other Network devices
=


Crypto devices using DPDK-compatible driver
===


Crypto devices using kernel driver
==


Other Crypto devices



Eventdev devices using DPDK-compatible driver
=


Eventdev devices using kernel driver



Other Eventdev devices
==


Mempool devices using DPDK-compatible driver



Mempool devices using kernel driver
===


Other Mempool devices
=

--

Thanks and regards,
Akın
;When present in device args, use_dpdk indicates you want DPDK to take over the 
UDP transports
;The value here represents a config, so you could have another section labeled 
use_dpdk=myconf
;instead and swap between them
[use_dpdk=1]
;dpdk_mtu is the NIC's MTU setting
;This is separate from MPM's maximum packet size
dpdk-mtu=9000
;dpdk_driver is the -d flag for the DPDK EAL. If DPDK doesn't pick up the 
driver for your NIC
;automatically, you may need this argument to point it to the folder where it 
can find the drivers
;Note that DPDK will attempt to load _everything_ in that folder as a driver, 
so you may want to
;create a separate folder with symlinks to the librte_pmd_* and 
librte_mempool_* libraries.
dpdk-driver=/home/ulak-gnb/ulak/dpdk-stable-17.11.9/x86_64-native-linuxapp-gcc/lib/pmds
;dpdk_corelist is the -l flag for the DPDK EAL. See more at the link
; 
https://doc.dpdk.org/guides-18.11/linux_gsg/build_sample_apps.html#running-a-sample-application
dpdk-corelist=5,6
;dpdk_num_mbufs is the total number of packet buffers allocated
;to each direction's packet buffer pool
;This will be multiplied by the number of NICs, but NICs on the same
;CPU socket share a pool.
dpdk-num-mbufs=4095
;dpdk_mbuf_cache_size is the number of buffers to cache for a CPU
;The cache reduces the interaction with the global pool
dpdk-mbuf-cache_size=315

[dpdk-mac=ac:1f:6b:78:5a:09]
;dpdk_lcore selects the lcore that this NIC's driver will run on
;Multiple NICs may occupy one lcore, but the I/O thread will completely
;consume that lcore's CPU. Also, 0 is reserved for the master thread (i.e.
;the initial UHD thread that calls init() for DPDK). Attempting to
;use it as an I/O thread will only result in hanging.
;Note also that by default, the lcore ID will be the same as the CPU ID.
dpdk-io-cpu = 5
;dpdk_ipv4 specifies the IPv4 address, and both the address and
;subnet mask are required (and in this format!). DPDK uses the
;netmask to create a basic routing table. Routing to other networks
;(i.e. via gateways) is not permitted.
dpdk-ipv4 = 10.10.1.5/24
;dpdk_num_desc is the number of descriptors in each DMA ring.
;Must be a power of 2.
;dpdk_num_desc=4096

[dpdk-mac=3c:fd:fe:a2:a9:0a]
dpdk-lcore = 6
dpdk-ipv4 = 10.10.1.5/24___
USRP-users mailing list
USRP-users@lists.ettus.com

Re: [USRP-users] USRP X310 PCIe connection Driver Problem

[akin soysal via USRP-users]

1.
>
>   http://files.ettus.com/manual/page_ni_rio_kernel.html
>   2.
>
>   Extract the files tar zxf niusrprio-installer-18.0.0.tar.gz
>   3.
>
>   Change to the extracted file’s directory cd niusrprio_installer
>   4.
>
>   Install ./INSTALL
>
>
> *Here is where I got it to work from trying things rather than
> following other instructions. I tried a lot of different things, so I’m not
> entirely sure, but I think this is what fixed it. See next section for
> other things I tried. ***
>
>
>1.
>
>The PCIe interface/cable cannot be plugged in while either the USRP or
>host computer are on, so turn both devices off. The order below is
>important!
>1.
>
>   Plug in PCIe cable
>   2.
>
>   Turn on SDR
>   3.
>
>   Turn on Computer
>   2.
>
>Connect over PCIe. You must use the stop command before the start
>command. It seems that the computer attempts to connect the USRP over PCIe
>when it boots, but does so incorrectly. You have to stop this process
>before you can start the correct PCIe connection. Use the following
>commands in this order:
>1.
>
>   sudo /usr/local/bin/niusrprio_pcie stop
>   2.
>
>   sudo /usr/local/bin/niusrprio_pcie start
>   3.
>
>   sudo /usr/local/bin/niusrprio_pcie status
>   3.
>
>Check that the usrp can be detected over PCIe. It should say that the
>resource is RIO0, but if it is something different, adjust that field in
>step 13.
>1.
>
>   uhd_find_devices
>   4.
>
>Load the .lvbitx images onto the USRP FPGA. The .lvbitx images are for
>PCIe connection and the .bit are for other interfaces.
>1.
>
>   uhd_image_loader --args="type=x300,RESOURCE=RIO0,fpga=HG"
>   --fpga-path="/usr/local/share/uhd/images/usrp_x310_fpga_HG.lvbitx
>   5.
>
>You need to restart the SDR for the FPGA image to take effect, but you
>must always turn off the computer before the SDR and stop the NI PCIe
>connection, so follow these steps to shut everything down:
>1.
>
>   Before turning off or disconnecting the USRP, you must always stop
>   the PCIe connection or else the system could become unstable: sudo
>   /usr/local/bin/niusrprio_pcie stop
>   2.
>
>   Turn off the SDR
>   3.
>
>   Turn off your computer
>   6.
>
>Repeat step 10 and 11 to turn everything on again.
>7.
>
>It should work now. This can be tested by repeating step 8.
>
>
> I believe those are the things that made my x310 PCIe connection work, but
> here are other things I recall trying which may have helped solve the
> problem:
>
>1.
>
>I don’t think this should be done, but I ran these lines:
>1.
>
>   http://files.ettus.com/manual/page_install.html
>   1.
>
>  sudo add-apt-repository ppa:ettusresearch/uhd
>  2.
>
>  sudo apt-get update
>  3.
>
>  sudo apt-get install libuhd-dev libuhd003 uhd-host
>  2.
>
>Fix gcc?
>1.
>
>
>   
> https://stackoverflow.com/questions/48398475/fail-to-install-gcc-4-9-in-ubuntu17-04
>
>
> mkdir ~/Downloads/gcc-4.9-deb && cd ~/Downloads/gcc-4.9-deb
>
> wget http://launchpadlibrarian.net/247707088/libmpfr4_3.1.4-1_amd64.deb
>
> wget
> http://launchpadlibrarian.net/253728424/libasan1_4.9.3-13ubuntu2_amd64.deb
>
> wget
> http://launchpadlibrarian.net/253728426/libgcc-4.9-dev_4.9.3-13ubuntu2_amd64.deb
>
> wget
> http://launchpadlibrarian.net/253728314/gcc-4.9-base_4.9.3-13ubuntu2_amd64.deb
>
> wget
> http://launchpadlibrarian.net/253728399/cpp-4.9_4.9.3-13ubuntu2_amd64.deb
>
> wget
> http://launchpadlibrarian.net/253728404/gcc-4.9_4.9.3-13ubuntu2_amd64.deb
>
> wget
> http://launchpadlibrarian.net/253728432/libstdc++-4.9-dev_4.9.3-13ubuntu2_amd64.deb
>
> wget
> http://launchpadlibrarian.net/253728401/g++-4.9_4.9.3-13ubuntu2_amd64.deb
>
> sudo dpkg -i gcc-4.9-base_4.9.3-13ubuntu2_amd64.deb
>
> sudo dpkg -i libmpfr4_3.1.4-1_amd64.deb
>
> sudo dpkg -i libasan1_4.9.3-13ubuntu2_amd64.deb
>
> sudo dpkg -i libgcc-4.9-dev_4.9.3-13ubuntu2_amd64.deb
>
> sudo dpkg -i cpp-4.9_4.9.3-13ubuntu2_amd64.deb
>
> sudo dpkg -i gcc-4.9_4.9.3-13ubuntu2_amd64.deb
>
> sudo dpkg -i libstdc++-4.9-dev_4.9.3-13ubuntu2_amd64.deb
>
> sudo dpkg -i g++-4.9_4.9.3-13ubuntu2_amd64.deb
>
>
> My hardware setup uses a laptop:
> Computer: Dell Precision 7730 (Laptop)
> XEON
> 32GB RAM
> 1TB SSD (EVO 970)
> Internal Intel GPU
> No

[USRP-users] How To Reset a Previously JTAG-Programmed Image For Use Over PCI-e Interface for USRP X310

[akin soysal via USRP-users]

Hello all,

I have a USRP X310 and I previously programmed it through JTAG with its
latest image for 10GbE.

Now I got a PCIe x4 cable and as far as I know, the image through this
interface is programmed for each session. I have read in a few places that
the JTAG programmed image could cause a problem.

If this is a problem, how can I reset it to default?

Thanks and regards,
Akın
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP X310 PCIe connection Driver Problem

[akin soysal via USRP-users]

OK, so I did manage to debug it further by setting the
ENABLE_EXTENDED_ERROR_INFO flag to true. It seems like the
nirio_driver_iface::rio_ioctl function is returning 52003 error.

uhd_usrp_probe --args "type=x300,resource=RIO0,fpga=HG"
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_3.13.1.HEAD-0-gbbce3e45
[INFO] [NIRIO] rpc_client stopping...
[INFO] [NIRIO] rpc_client stopped.
ERROR: The following function call returned status code -52003
nirio_driver_iface::rio_ioctl(_device_handle, NIRIO_IOCTL_POST_OPEN, NULL,
0, NULL, 0)
/home/ulak/uhd/uhd/host/lib/transport/nirio/niriok_proxy_impl_v1.cpp:438
[INFO] [NIRIO] rpc_client stopping...
[INFO] [NIRIO] rpc_client stopped.
ERROR: The following function call returned status code -52003
nirio_driver_iface::rio_ioctl(_device_handle, NIRIO_IOCTL_POST_OPEN, NULL,
0, NULL, 0)
/home/ulak/uhd/uhd/host/lib/transport/nirio/niriok_proxy_impl_v1.cpp:438
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Connecting to niusrpriorpc at localhost:5444...
ERROR: The following function call returned status code -52003
nirio_driver_iface::rio_ioctl(_device_handle, NIRIO_IOCTL_POST_OPEN, NULL,
0, NULL, 0)
/home/ulak/uhd/uhd/host/lib/transport/nirio/niriok_proxy_impl_v1.cpp:438
[INFO] [NIRIO] rpc_client stopping...
[INFO] [NIRIO] rpc_client stopped.
[INFO] [X300] Using LVBITX bitfile /home/ulak/usrp_x310_fpga_HG.lvbitx...
ERROR: The following function call returned status code -52003
nirio_driver_iface::rio_ioctl(_device_handle, NIRIO_IOCTL_POST_OPEN, NULL,
0, NULL, 0)
/home/ulak/uhd/uhd/host/lib/transport/nirio/niriok_proxy_impl_v1.cpp:438
[INFO] [NIRIO] rpc_client stopping...
[INFO] [NIRIO] rpc_client stopped.
ERROR: The following function call returned status code -63150
_rpc_client.niusrprio_open_session( _resource_name, bitfile_path,
signature, download_fpga)
/home/ulak/uhd/uhd/host/lib/transport/nirio/niusrprio_session.cpp:80
ERROR: The following function call returned status code -63150
mb.rio_fpga_interface->open(lvbitx, dev_addr.has_key("download-fpga"))
/home/ulak/uhd/uhd/host/lib/usrp/x300/x300_impl.cpp:609
[INFO] [NIRIO] rpc_client stopping...
[INFO] [NIRIO] rpc_client stopped.
Error: RuntimeError: x300_impl: Could not initialize RIO session. Unknown
error. (Error code -63150)





On Tue, Mar 5, 2019 at 1:32 PM akin soysal  wrote:

> Dear all,
>
> I am trying to connect over PCIe to my USRP X310. I have installed the
> latest drivers niusrprio-installer-18.0.0.tar.gz and I am starting the PCIe
> connection with the following command:
>
> sudo /usr/local/bin/niusrprio_pcie start
> Making sure drivers are up to date...
> Module nikal is up-to-date
> Module nibds is up-to-date
> Module nistreamk is up-to-date
> Module NiRioSrv is up-to-date
> Module niusrpriok is up-to-date
> Loading: NiRioSrv niusrpriok
> Starting: niusrpriorpc
>
> Then I try the uhd_usrp_probe:
>
> uhd_usrp_probe --args "type=x300,resource=RIO0"
> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_3.13.1.HEAD-0-gbbce3e45
> [INFO] [NIRIO] rpc_client stopping...
> [INFO] [NIRIO] rpc_client stopped.
> [INFO] [NIRIO] rpc_client stopping...
> [INFO] [NIRIO] rpc_client stopped.
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Connecting to niusrpriorpc at localhost:5444...
> [INFO] [NIRIO] rpc_client stopping...
> [INFO] [NIRIO] rpc_client stopped.
> [INFO] [X300] Using LVBITX bitfile
> /usr/local/share/uhd/images/usrp_x310_fpga_HG.lvbitx...
> [INFO] [NIRIO] rpc_client stopping...
> [INFO] [NIRIO] rpc_client stopped.
> [INFO] [NIRIO] rpc_client stopping...
> [INFO] [NIRIO] rpc_client stopped.
> Error: RuntimeError: x300_impl: Could not initialize RIO session. Unknown
> error. (Error code -63150)
>
> I have another PC and USRP x310 and this is working fine. I have followed
> the exact same steps and there isn't any issue. What could be the problem
> and how can I debug this further?
>
> Regards,
> Akın
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] USRP X310 PCIe connection Driver Problem

[akin soysal via USRP-users]

Dear all,

I am trying to connect over PCIe to my USRP X310. I have installed the
latest drivers niusrprio-installer-18.0.0.tar.gz and I am starting the PCIe
connection with the following command:

sudo /usr/local/bin/niusrprio_pcie start
Making sure drivers are up to date...
Module nikal is up-to-date
Module nibds is up-to-date
Module nistreamk is up-to-date
Module NiRioSrv is up-to-date
Module niusrpriok is up-to-date
Loading: NiRioSrv niusrpriok
Starting: niusrpriorpc

Then I try the uhd_usrp_probe:

uhd_usrp_probe --args "type=x300,resource=RIO0"
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_3.13.1.HEAD-0-gbbce3e45
[INFO] [NIRIO] rpc_client stopping...
[INFO] [NIRIO] rpc_client stopped.
[INFO] [NIRIO] rpc_client stopping...
[INFO] [NIRIO] rpc_client stopped.
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Connecting to niusrpriorpc at localhost:5444...
[INFO] [NIRIO] rpc_client stopping...
[INFO] [NIRIO] rpc_client stopped.
[INFO] [X300] Using LVBITX bitfile
/usr/local/share/uhd/images/usrp_x310_fpga_HG.lvbitx...
[INFO] [NIRIO] rpc_client stopping...
[INFO] [NIRIO] rpc_client stopped.
[INFO] [NIRIO] rpc_client stopping...
[INFO] [NIRIO] rpc_client stopped.
Error: RuntimeError: x300_impl: Could not initialize RIO session. Unknown
error. (Error code -63150)

I have another PC and USRP x310 and this is working fine. I have followed
the exact same steps and there isn't any issue. What could be the problem
and how can I debug this further?

Regards,
Akın
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP X310 GPS or IEEE 1588 Synchronization

[akin soysal via USRP-users]

Hello,

I know that the 10GbE ethernet interface is adding an extra 500us round
trip time delay with fiber DAC. I tested it myself. 1 GbE would probably
give a similar delay as well. So do you think it would stay below our delay
budget of 250us?

Regards,
Akın

On Fri, 1 Mar 2019 00:24 Nate Temple  Hi Rob,
>
> Yes, that's correct, you can use the WR-LEN with the X310.
>
> Regards,
> Nate Temple
>
>
>
>
>
>
> On Wed, Feb 27, 2019 at 12:40 PM Rob Kossler  wrote:
>
>> Nate,
>> Although the X3xx series to not natively support White Rabbit, I believe
>> that they can get all of the benefits by using a WR-LEN in close proximity
>> to the X310.  Is that correct?
>>
>> Rob
>>
>> On Wed, Feb 27, 2019 at 11:45 AM Nate Temple via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi Akin,
>>>
>>> The Octoclock-G would be suitable for this purpose, and yes, it does
>>> contain a GPSDO (OCXO). https://kb.ettus.com/GPSDO#GPSDO_.28OCXO.29
>>>
>>> The Octoclock-G does not contain an antenna, you must provide one to the
>>> GPS Antenna input (SMA).
>>>
>>> The X3xx series do not support IEEE 1588, however, the N3xx series USRPs
>>> do support White Rabbit, which is an extension of the IEEE-1588-2008
>>> standard. More info can be found here on it
>>> https://kb.ettus.com/Using_Ethernet-Based_Synchronization_on_the_USRP%E2%84%A2_N3xx_Devices
>>>
>>>
>>> Regards,
>>> Nate Temple
>>>
>>> On Wed, Feb 27, 2019 at 8:31 AM akin soysal via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
>>>> Hello All,
>>>>
>>>>
>>>> I have a question. We want to synchronize the clock of the two USRP
>>>> X310s with a GPS or IEEE 1588 standard. I would like to synchronize the two
>>>> USRPs with each other so that the base station and user terminal would not
>>>> experience any synchronization issue. I also would like to synchronize one
>>>> of the USRP X310s with an external base station, which supports IEEE 1588
>>>> and GPS clocks, and we have a synchronization budget of about *250us*.
>>>>
>>>>
>>>> I learned that the setup that worked in France is using the following
>>>> Ettus product:
>>>>
>>>>
>>>> https://www.ettus.com/product/details/OctoClock-G
>>>>
>>>>
>>>> Do you think that this would suffice for our needs? It has its own GPS
>>>> clock and antenna inside, right? It is compatible with USRP X310?
>>>>
>>>>
>>>> I know that the product specification does not include IEEE 1588, so I
>>>> am concluding that it would not be possible to use this standard for our
>>>> scenario, do you agree?
>>>>
>>>> Thanks and regards,
>>>>
>>>> Akın
>>>> ___
>>>> 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
>>>
>>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] USRP X310 GPS or IEEE 1588 Synchronization

[akin soysal via USRP-users]

Hello All,


I have a question. We want to synchronize the clock of the two USRP X310s
with a GPS or IEEE 1588 standard. I would like to synchronize the two USRPs
with each other so that the base station and user terminal would not
experience any synchronization issue. I also would like to synchronize one
of the USRP X310s with an external base station, which supports IEEE 1588
and GPS clocks, and we have a synchronization budget of about *250us*.


I learned that the setup that worked in France is using the following Ettus
product:


https://www.ettus.com/product/details/OctoClock-G


Do you think that this would suffice for our needs? It has its own GPS
clock and antenna inside, right? It is compatible with USRP X310?


I know that the product specification does not include IEEE 1588, so I am
concluding that it would not be possible to use this standard for our
scenario, do you agree?

Thanks and regards,

Akın
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] USRP X310 Maximum frame size: 7972 bytes.

[akin soysal via USRP-users]

Hello,

In order to decrease the latency, I was playing around with the MTU size
setting it to 4000, 7000, 9000 and now a permanent error happens in my
server connected to USRP. I tried it with two different USRP X310s and the
problem happens in both. Where does the 7972 bytes come from? Thanks.
Regards, Akın

/uhd/uhd/host/build$ uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_3.13.1.HEAD-0-gbbce3e45
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 7972 bytes.
[INFO] [X300] Radio 1x clock: 200 MHz
[WARNING] [X300] For this connection, UHD recommends a send frame size of
at least 8000 for best
performance, but your system's MTU will only allow 7972.This will
negatively impact your maximum achievable sample rate.
[WARNING] [X300] For this connection, UHD recommends a receive frame size
of at least 8000 for best
performance, but your system's MTU will only allow 7972.This will
negatively impact your maximum achievable sample rate.
[WARNING] [X300] For this connection, UHD recommends a send frame size of
at least 8000 for best
performance, but your system's MTU will only allow 7972.This will
negatively impact your maximum achievable sample rate.
[WARNING] [X300] For this connection, UHD recommends a receive frame size
of at least 8000 for best
performance, but your system's MTU will only allow 7972.This will
negatively impact your maximum achievable sample rate.
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D000)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1306 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1311 MB/s)
[WARNING] [X300] For this connection, UHD recommends a send frame size of
at least 8000 for best
performance, but your system's MTU will only allow 7972.This will
negatively impact your maximum achievable sample rate.
[WARNING] [X300] For this connection, UHD recommends a receive frame size
of at least 8000 for best
performance, but your system's MTU will only allow 7972.This will
negatively impact your maximum achievable sample rate.
[WARNING] [X300] For this connection, UHD recommends a send frame size of
at least 8000 for best
performance, but your system's MTU will only allow 7972.This will
negatively impact your maximum achievable sample rate.
[WARNING] [X300] For this connection, UHD recommends a receive frame size
of at least 8000 for best
performance, but your system's MTU will only allow 7972.This will
negatively impact your maximum achievable sample rate.
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1001)
[WARNING] [X300] For this connection, UHD recommends a send frame size of
at least 8000 for best
performance, but your system's MTU will only allow 7972.This will
negatively impact your maximum achievable sample rate.
[WARNING] [X300] For this connection, UHD recommends a receive frame size
of at least 8000 for best
performance, but your system's MTU will only allow 7972.This will
negatively impact your maximum achievable sample rate.
[WARNING] [X300] For this connection, UHD recommends a send frame size of
at least 8000 for best
performance, but your system's MTU will only allow 7972.This will
negatively impact your maximum achievable sample rate.
[WARNING] [X300] For this connection, UHD recommends a receive frame size
of at least 8000 for best
performance, but your system's MTU will only allow 7972.This will
negatively impact your maximum achievable sample rate.
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD1001)
[WARNING] [X300] For this connection, UHD recommends a send frame size of
at least 8000 for best
performance, but your system's MTU will only allow 7972.This will
negatively impact your maximum achievable sample rate.
[WARNING] [X300] For this connection, UHD recommends a receive frame size
of at least 8000 for best
performance, but your system's MTU will only allow 7972.This will
negatively impact your maximum achievable sample rate.
[WARNING] [X300] For this connection, UHD recommends a send frame size of
at least 8000 for best
performance, but your system's MTU will only allow 7972.This will
negatively impact your maximum achievable sample rate.
[WARNING] [X300] For this connection, UHD recommends a receive frame size
of at least 8000 for best
performance, but your system's MTU will only allow 7972.This will
negatively impact your maximum achievable sample rate.
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
[WARNING] [X300] For this connection, UHD recommends a send frame size of
at least 8000 for best
performance, but your system's MTU will only allow 7972.This will
negatively impact your maximum achievable sample rate.
[WARNING] [X300] For this connection, UHD recommends a receive frame size
of at least 8000 for best
performance, but your system's MTU will only allow 7972.This will
negatively impact your maximum achievable sample rate.
[WARNING] [X300] For this connection, UHD recommends a send 

Re: [USRP-users] Fwd: USRP X310 Ubuntu 16.04 LowLatency Timing Problems Possibly Because of UHD Drivers

[akin soysal via USRP-users]

Oh, OK. So I think this test passes, the output is below. I also double
checked that I could set the 184.32e6 frequency when I am trying to run the
actual code. But still I have timing related problems. So how can I further
debug my timing problems?

sudo ./tx_samples_from_file --rate 61.44e6 --args
master_clock_rate=184.32e6 --freq=3.5e9

Creating the usrp device with: master_clock_rate=184.32e6...
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_3.13.1.HEAD-0-gbbce3e45
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 8000 bytes.
[INFO] [X300] Radio 1x clock: 184.32 MHz
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D000)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1300 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1319 MB/s)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1001)
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD1001)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0)
Using Device: Single USRP:
  Device: X-Series Device
  Mboard 0: X310
  RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: CBX-120 RX
  RX Channel: 1
RX DSP: 0
RX Dboard: B
RX Subdev: CBX-120 RX
  TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: CBX-120 TX
  TX Channel: 1
TX DSP: 0
TX Dboard: B
TX Subdev: CBX-120 TX

Setting TX Rate: 61.44 Msps...
[WARNING] [RFNOC] The requested interpolation is odd; the user should
expect passband CIC rolloff.
Select an even interpolation to ensure that a halfband filter is enabled.
interpolation = dsp_rate/samp_rate -> 3 = (184.32 MHz)/(61.44 MHz)

[WARNING] [RFNOC] The requested interpolation is odd; the user should
expect passband CIC rolloff.
Select an even interpolation to ensure that a halfband filter is enabled.
interpolation = dsp_rate/samp_rate -> 3 = (184.32 MHz)/(61.44 MHz)

Actual TX Rate: 61.44 Msps...

Setting TX Freq: 3500.00 MHz...
Actual TX Freq: 3500.00 MHz...

Checking TX: LO: locked ...

Done!

On Fri, Feb 8, 2019 at 9:54 PM Marcus D. Leech 
wrote:

> On 02/08/2019 01:31 PM, akin soysal wrote:
>
> I tried setting it with the following command:
>
> uhd_usrp_probe --args="master_clock_rate=184.32e6"
> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_3.13.1.HEAD-0-gbbce3e45
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Maximum frame size: 8000 bytes.
> [INFO] [X300] Radio 1x clock: 184.32 MHz
>
> Master clock rate is a *PER SESSION* parameter!   You need to specify it
> in the device arguments of applications.
>
> tx_samples_from_file -a "type=x300,master_clock_rate=182.32e6"
>
> And then the rest of your parameters.
>
>
> It seems to work in the beginning but when I repeat the previous command,
> I see that master clock rate is set back to 200 MHz.
>
> sudo ./tx_samples_from_file --rate 61.44e6
>
> Creating the usrp device with: ...
> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_3.13.1.HEAD-0-gbbce3e45
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Maximum frame size: 8000 bytes.
> [INFO] [X300] Radio 1x clock: 200 MHz
>
> Then I found the following useful thread, it was first said that only
> 200MHz is supported but then it was said that 184.32MHz is also supported
> so I cannot be sure.
>
> http://ettus.80997.x6.nabble.com/USRP-users-Clock-rate-of-x310-td9744.html
>
> Is there a way to set the 184.32 MHz clock rate and if yes, is it possible
> to set it as default?
>
> Thanks.
>
>
> On Fri, Feb 8, 2019 at 5:24 PM Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 02/08/2019 04:37 AM, akin soysal via USRP-users wrote:
>>
>> I am resending the mail to the forum so that everybody benefits.
>>
>> -- Forwarded message -
>> From: akin soysal 
>> Date: Fri, Feb 8, 2019 at 10:29 AM
>> Subject: Re: [USRP-users] USRP X310 Ubuntu 16.04 LowLatency Timing
>> Problems Possibly Because of UHD Drivers
>> To: Marcus D. Leech 
>>
>>
>> Hello Marcus,
>>
>> OK, I tried, it seems the HW is not supporting the desired rate. It is a
>> NI CBX120 MHz daughterboard with USRP X310. Does that make sense? I thought
>> these sample rates were specifically for this HW??
>>
>> ulak@5g-NR-gNB:/usr/local/lib/uhd/examples$ sudo ./tx_samples_from_file
>> --rate 61.44e6
>>
>>
>> Include "master_clock_rate=184.32e6" in your device argume

[USRP-users] Fwd: USRP X310 Ubuntu 16.04 LowLatency Timing Problems Possibly Because of UHD Drivers

[akin soysal via USRP-users]

I am resending the mail to the forum so that everybody benefits.

-- Forwarded message -
From: akin soysal 
Date: Fri, Feb 8, 2019 at 10:29 AM
Subject: Re: [USRP-users] USRP X310 Ubuntu 16.04 LowLatency Timing Problems
Possibly Because of UHD Drivers
To: Marcus D. Leech 


Hello Marcus,

OK, I tried, it seems the HW is not supporting the desired rate. It is a NI
CBX120 MHz daughterboard with USRP X310. Does that make sense? I thought
these sample rates were specifically for this HW??

ulak@5g-NR-gNB:/usr/local/lib/uhd/examples$ sudo ./tx_samples_from_file
--rate 61.44e6

Creating the usrp device with: ...
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_3.13.1.HEAD-0-gbbce3e45
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 8000 bytes.
[INFO] [X300] Radio 1x clock: 200 MHz
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D000)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1302 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1313 MB/s)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1001)
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD1001)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0)
Using Device: Single USRP:
  Device: X-Series Device
  Mboard 0: X310
  RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: CBX-120 RX
  RX Channel: 1
RX DSP: 0
RX Dboard: B
RX Subdev: CBX-120 RX
  TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: CBX-120 TX
  TX Channel: 1
TX DSP: 0
TX Dboard: B
TX Subdev: CBX-120 TX

Setting TX Rate: 61.44 Msps...
[WARNING] [RFNOC] The requested interpolation is odd; the user should
expect passband CIC rolloff.
Select an even interpolation to ensure that a halfband filter is enabled.
interpolation = dsp_rate/samp_rate -> 3 = (200.00 MHz)/(61.44 MHz)

[WARNING] [RFNOC] The requested interpolation is odd; the user should
expect passband CIC rolloff.
Select an even interpolation to ensure that a halfband filter is enabled.
interpolation = dsp_rate/samp_rate -> 3 = (200.00 MHz)/(61.44 MHz)

[WARNING] [MULTI_USRP] The hardware does not support the requested TX
sample rate:
Target sample rate: 61.44 MSps
Actual sample rate: 66.67 MSps

[WARNING] [MULTI_USRP] The hardware does not support the requested TX
sample rate:
Target sample rate: 61.44 MSps
Actual sample rate: 66.67 MSps

Actual TX Rate: 66.67 Msps...

Please specify the center frequency with --freq

On Thu, Feb 7, 2019 at 5:18 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 02/07/2019 08:50 AM, akin soysal via USRP-users wrote:
>
> Dear all,
>
>
> We are trying to make the OpenAirInterface 5G SW work on our own setup
> with NI USRPs. We are trying to use it with the following configuration:
>
>
> sudo ./benchmark_rate --args
> "type=x300,addr=10.10.1.5,master_clock_rate=184.32e6" --rx_rate 61.44e6
> --tx_rate 61.44e6 --channels="0"
>
>
> For different UHD versions we get different results. Firstly, we know that
> the OAI setup in France is using the following driver and gives the
> following output:
>
>
> ---
> [0m[PHY]  Checking for USRPs : UHD 003.009.007-0-g50839059 (3.9.7)
> [0m[PHY]  Found USRP X300
> [0m[PHY]  ru_thread_prach() RACH waiting for RU to be configured
> -- X300 initialization sequence...
> -- Connecting to niusrpriorpc at localhost:5444...
> -- Using LVBITX bitfile
> /usr/local/share/uhd/images/usrp_x310_fpga_HGS.lvbitx...
> [0m[PHY]  ru_thread_prach() RACH waiting for RU to be configured
> [0m[PHY]  ru_thread_prach() RACH waiting for RU to be configured
> [0m[PHY]  ru_thread_prach() RACH waiting for RU to be configured
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:184.32
> -- Detecting internal GPSDO Found an internal GPSDO: LC_XO, Firmware
> Rev 0.929a
> ---
>
>
> We tried the same configuration, but we got errors:
>
>
> ---
> ulak@5g-NR-gNB:/usr/local/lib/uhd/examples$ sudo ./benchmark_rate --args
> "type=x300,addr=10.10.1.5,master_clock_rate=184.32e6" --rx_rate 61.44e6
> --tx_rate 61.44e6 --channels="0"
> [sudo] password for ulak:
> linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_003.009.007-0-g50839059
>
>
> Creating the usrp device with:
> type=x300,addr=10.10.1.5,master_clock_rate=184.32e6...
> -- X300 initialization sequence...
> -- Determining maximum frame size... 8000 bytes.
> -- Setup basic communication...
> -