[USRP-users] Re: DPDK drops samples at low rates

2021-11-16 Thread Marcus D. Leech 

On 2021-11-16 03:11, Guillermo Ortas Delgado wrote:


No reason, just testing for the maximum supported MTU by DPDK. Any 
higher than that will throw an error. Setting the parameter to 9000 
doesn’t make any difference wrt to 9600, or even a lower value in my case.


Also, I have observed this behavior when trying to increase the 
descriptors


·dpdk_num_mbufs=4096and dpdk_num_desc=2048àbenchmark_ratefails to 
launch (gets stuck after [INFO] [X300] X300 initialization sequence...)


·dpdk_num_mbufs=8192and dpdk_num_desc=2048àbenchmark_rate launches and 
completes, but throws plenty of errors in the process saying 
bnxt_rx_pkt(): mbuf alloc failed, dropping plenty of samples (i.e. 3%) 
even at 25Msps and timeouts happen.


·dpdk_num_mbufs=32768and dpdk_num_desc=4096àbenchmark_ratelaunches and 
completes with no error messages, but drops plenty of samples (i.e. 
3%) even at 25Msps, but no timeouts.


All of the above happens with the [INFO] [X300] Maximum frame size: 
1556 bytesmessage that started this thread.


bnxtis the driver that DPDK loads to manage the eight (8) Broadcom 
BCM57414 NetXtreme-E 10Gb network interfaces that I have to manage my 
four (4) USRPs X310. For this test I’m just using two interfaces for a 
single x310.


Any ideas?

Best,

Guillermo


*So, for DPDK 18.11, which is the version supported by current UHD, I 
see NO evidence that DPDK even supports the bnxt driver--only Intel and 
Mellanox.


But I understand that can be mis-leading.  The fact that it was never 
tested against a given 10G NIC driver doesn't mean that it won't work.


https://doc.dpdk.org/guides-19.08/rel_notes/release_18_11.html#

*___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: DPDK drops samples at low rates

2021-11-16 Thread Rob Kossler 
This page  indicates it
has some support.

On Tue, Nov 16, 2021 at 12:30 PM Marcus D. Leech 
wrote:

> On 2021-11-16 03:11, Guillermo Ortas Delgado wrote:
>
> No reason, just testing for the maximum supported MTU by DPDK. Any higher
> than that will throw an error. Setting the parameter to 9000 doesn’t make
> any difference wrt to 9600, or even a lower value in my case.
>
>
>
> Also, I have observed this behavior when trying to increase the descriptors
>
> · dpdk_num_mbufs=4096 and dpdk_num_desc=2048 à benchmark_rate
> fails to launch (gets stuck after [INFO] [X300] X300 initialization
> sequence...)
>
> · dpdk_num_mbufs=8192 and dpdk_num_desc=2048 à benchmark_rate
>  launches and completes, but throws plenty of errors in the process saying 
> bnxt_rx_pkt():
> mbuf alloc failed, dropping plenty of samples (i.e. 3%) even at 25Msps
> and timeouts happen.
>
> · dpdk_num_mbufs=32768 and dpdk_num_desc=4096 à benchmark_rate
> launches and completes with no error messages, but drops plenty of samples
> (i.e. 3%) even at 25Msps, but no timeouts.
>
>
>
> All of the above happens with the [INFO] [X300] Maximum frame size: 1556
> bytes message that started this thread.
>
>
>
> bnxt is the driver that DPDK loads to manage the eight (8) Broadcom
> BCM57414 NetXtreme-E 10Gb network interfaces that I have to manage my four
> (4) USRPs X310. For this test I’m just using two interfaces for a single
> x310.
>
>
>
> Any ideas?
>
>
>
> Best,
>
> Guillermo
>
>
>
>
>
>
>
>
>
> *So, for DPDK 18.11, which is the version supported by current UHD, I see
> NO evidence that DPDK even supports the bnxt driver--only Intel and
> Mellanox. But I understand that can be mis-leading.  The fact that it was
> never tested against a given 10G NIC driver doesn't mean that it won't
> work. https://doc.dpdk.org/guides-19.08/rel_notes/release_18_11.html#
>  *
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] rfnoc_graph->synchronize_devices()

2021-11-16 Thread Rob Kossler 
Hi,
I recently stumbled across this synchonize_devices() function and I'm
wondering if I need to be calling it.  I ran grep in the UHD source folder
and there are no examples of calling this function.  I read the help but
it's not clear to me how this function differs from calling
set_time_next_pps() on all of the motherboards (such as is done in the
lib/multi_usrp_rfnoc.cpp code).  My thought process is: if multi_usrp_rfnoc
does not need to call synchonize_devices(), why would my custom application
need to call it?  Any help would be appreciated.

Thanks.
Rob
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] gps_locked sensor indicating internal GPSDO lock too early

2021-11-16 Thread schneider 
Hi,

I've experienced and issue while working with the internal GPSDO (TCXO
option) of an USRP B210: a call to `get_mboard_sensor("gps_locked", 0)`
can return `true` even if the (Jackson Labs) GPSDO is not properly
locked yet.

The reason seems to be that the "gps_locked" sensor is looking at a
field in the GPGGA sentence which can change from "0" to "1" before the
GPSDO is properly locked.

I've collected some debug traces, consisting of SERVO, GPGGA and GPRMC
sentences (as defined in `lib/usrp/gps_ctrl.cpp`). They are attached at
the end of this mail.

Index 6 of the GPGGA sentence is used by the "gps_locked" sensor.

Index 7 of the SERVO sentence actually indicates lock status of a
Jackson Labs GPSDO (as defined on page 40 of the user manual:
http://www.jackson-labs.com/assets/uploads/main/LC_XO_Manual.pdf). A
value of "6" indicates a proper lock.

It can be seen that index 6 of the GPGGA does not actually reflect the
GPSDO lock state in a meaningful way. The USRP was already running for
some time and the GPS module already knew where it was located. It
however did not have an accurate time yet (as indicated by the
2006-01-01 date in the SERVO and GPRMC sentences). In an application
waiting for a lock this bogus time would then be used to set the next PPS.

Afterwards the SERVO sentence starts to change and after some time
arrives at a proper date with a proper lock.


I'm wondering how a good solution to his could look like. The SERVO
sentence is obviously specific to the Jackson Labs module. Other
(internal) GPSDOs might behave differently (they do exist...). Otherwise
I would have recommended to change the "gps_locked" sensor to use the
SERVO sentence instead of the GPGGA sentence.

Best
schneider


Logs:

1637105473: Mi 17. Nov 00:31:13 CET 2021
SERVO: 06-01-01 0 45293 0.00 1.00E-08 10 5 1 0x38
GPGGA:
$GPGGA,002547.00,.,N,X.,E,1,04,11.8,306.2,M,46.2,M,,*58
get_mboard_sensor("gps_locked", 0)---^
GPRMC: $GPRMC,002548.00,A,4808.8745,N,01134.7031,E,11.1,79.2,010106,,*3B

[]

1637105608: Mi 17. Nov 00:33:28 CET 2021
SERVO: 06-01-01 0 45293 0.00 1.00E-08 10 7 1 0x38
GPGGA:
$GPGGA,002801.00,.,N,X.,E,1,06,1.3,548.2,M,46.3,M,,*65

1637105609: Mi 17. Nov 00:33:29 CET 2021
SERVO: 06-01-01 1416 45293 0.00 1.00E-08 10 7 2 0x20
GPGGA:
$GPGGA,002802.00,.,N,X.,E,1,06,1.3,548.1,M,46.3,M,,*68

1637105610: Mi 17. Nov 00:33:30 CET 2021
SERVO: 21-11-16 1417 45293 0.00 2.00E-09 10 7 2 0x0
GPGGA:
$GPGGA,20.00,.,N,X.,E,1,06,1.3,547.8,M,46.3,M,,*6B

[.]

1637105640: Mi 17. Nov 00:34:00 CET 2021
SERVO: 21-11-16 1447 44718 -4.26 -1.42E-10 10 7 2 0x0
GPGGA:
$GPGGA,233400.00,.,N,X.,E,1,06,1.3,557.6,M,46.3,M,,*65

1637105641: Mi 17. Nov 00:34:01 CET 2021
SERVO: 21-11-16 1448 44667 -4.62 -1.49E-10 10 7 6 0x0
Jackson Labs GPSDO actually locked -^
GPGGA:
$GPGGA,233401.00,.,N,X.,E,1,06,1.3,558.2,M,46.3,M,,*68
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: gps_locked sensor indicating internal GPSDO lock too early

2021-11-16 Thread Marcus D. Leech 

On 2021-11-16 19:12, schneider wrote:

Hi,

I've experienced and issue while working with the internal GPSDO (TCXO
option) of an USRP B210: a call to `get_mboard_sensor("gps_locked", 0)`
can return `true` even if the (Jackson Labs) GPSDO is not properly
locked yet.

The reason seems to be that the "gps_locked" sensor is looking at a
field in the GPGGA sentence which can change from "0" to "1" before the
GPSDO is properly locked.

I've collected some debug traces, consisting of SERVO, GPGGA and GPRMC
sentences (as defined in `lib/usrp/gps_ctrl.cpp`). They are attached at
the end of this mail.

Index 6 of the GPGGA sentence is used by the "gps_locked" sensor.

Index 7 of the SERVO sentence actually indicates lock status of a
Jackson Labs GPSDO (as defined on page 40 of the user manual:
http://www.jackson-labs.com/assets/uploads/main/LC_XO_Manual.pdf). A
value of "6" indicates a proper lock.

It can be seen that index 6 of the GPGGA does not actually reflect the
GPSDO lock state in a meaningful way. The USRP was already running for
some time and the GPS module already knew where it was located. It
however did not have an accurate time yet (as indicated by the
2006-01-01 date in the SERVO and GPRMC sentences). In an application
waiting for a lock this bogus time would then be used to set the next PPS.

Afterwards the SERVO sentence starts to change and after some time
arrives at a proper date with a proper lock.


I'm wondering how a good solution to his could look like. The SERVO
sentence is obviously specific to the Jackson Labs module. Other
(internal) GPSDOs might behave differently (they do exist...). Otherwise
I would have recommended to change the "gps_locked" sensor to use the
SERVO sentence instead of the GPGGA sentence.

Best
schneider


Logs:

1637105473: Mi 17. Nov 00:31:13 CET 2021
SERVO: 06-01-01 0 45293 0.00 1.00E-08 10 5 1 0x38
GPGGA:
$GPGGA,002547.00,.,N,X.,E,1,04,11.8,306.2,M,46.2,M,,*58
 get_mboard_sensor("gps_locked", 0)---^
GPRMC: $GPRMC,002548.00,A,4808.8745,N,01134.7031,E,11.1,79.2,010106,,*3B

[]

1637105608: Mi 17. Nov 00:33:28 CET 2021
SERVO: 06-01-01 0 45293 0.00 1.00E-08 10 7 1 0x38
GPGGA:
$GPGGA,002801.00,.,N,X.,E,1,06,1.3,548.2,M,46.3,M,,*65

1637105609: Mi 17. Nov 00:33:29 CET 2021
SERVO: 06-01-01 1416 45293 0.00 1.00E-08 10 7 2 0x20
GPGGA:
$GPGGA,002802.00,.,N,X.,E,1,06,1.3,548.1,M,46.3,M,,*68

1637105610: Mi 17. Nov 00:33:30 CET 2021
SERVO: 21-11-16 1417 45293 0.00 2.00E-09 10 7 2 0x0
GPGGA:
$GPGGA,20.00,.,N,X.,E,1,06,1.3,547.8,M,46.3,M,,*6B

[.]

1637105640: Mi 17. Nov 00:34:00 CET 2021
SERVO: 21-11-16 1447 44718 -4.26 -1.42E-10 10 7 2 0x0
GPGGA:
$GPGGA,233400.00,.,N,X.,E,1,06,1.3,557.6,M,46.3,M,,*65

1637105641: Mi 17. Nov 00:34:01 CET 2021
SERVO: 21-11-16 1448 44667 -4.62 -1.49E-10 10 7 6 0x0
 Jackson Labs GPSDO actually locked -^
GPGGA:
$GPGGA,233401.00,.,N,X.,E,1,06,1.3,558.2,M,46.3,M,,*68
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
Interesting, because the LC_XO module ALSO has a "lock_ok" pin, which is 
what I *thought* the drivers were looking at.


It could be the case that particular pin is ALSO not a reliable 
indication of TIME lock, and they moved to using GPGGA instead.


___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] USRP x310 ERROR_CODE_OVERFLOW issue

2021-11-16 Thread LoyCurtis Smith 
Hi,

I am attempting to use two USRP x310 to deploy a 5G SA networking using the
openairinterface5g open-source system. However, I am experiencing a receive
overflow error when attempting to deploy both an OAI-nrUE and OAI-gNB.


The nrUE gives an *ERROR_CODE_OVERFLOW (Overflow) *warning before failing
and referencing a function in the OAI code.


My gNB runs irregularly, constantly showing the
*ERROR_CODE_OVERFLOW(Overflow) *message. In addition to multiple late or
"L" messages.


My system setting is as follows:

   - *OAI-nrUE* - Latitude -E5570* (laptop)* - 16 GB RAM, i7-6820HQ with 4
   cores, 8 threads @ 2.70 GHz running Ubuntu 18.04 with 5.40-90 low latency
   kernel; 1-GigE connection to USRP x310 with CBX-120 daughterboard. UHD 3.15
   - *OAI-gNB* - Optiplex-7040* (desktop)** - *16 GB RAM, i7-6700 with 4
   cores, 8 threads @ 3.40 GHz- running Ubuntu 18.04 with 5.40-89 low latency
   kernel; 1-GigE connection to USRP x310 with CBX-120 daughterboard. UHD 4.1


I've made the following changes to both systems:

   - Set the socket buffers (rmem_default, rmem_max, wmem_max,
   wmem_default) to 33554432
   - Set TX and RX ring buffers on the interface to max value of 4096.
   - Set scaling_governor to "performance" mode for each CPU.
   - Disabled C states.
   - Performed self-calibration on OAI-nrUE USRP x310 using
   uhd_cal_rx_iq_balance, uhd_cal_tx_iq_balance, and uhd_cal_tx_dc_offset.


Do you have any recommendations for my overflow issues? Also, Is there a
way to lower the number of samples transmitted?

Additionally, I tried to run the UHD benchmark test in examples. However, I
had issues converting the cpp file to an executable. It failed for some
reason. Do you have any advice for this as well?

-- 

V/r

LoyCurtis Smith
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com