On 2021-11-04 13:40, Guillermo Ortas Delgado wrote:
Thank you Rob and Marcus,
Is there a specific page or resource that I should read for guidance?
Anything in particular that I should keep in mind?
I would really appreciate it, especially if there are so many gotchas
as you say.
Best,
Guillermo
I don't use it myself, so I have no experience to convey.
DPDK wouldn't even be necessary if the OS kernel-layer network drivers
were "up" to the task of
very-high rate continuous streaming. They aren't. Which is why DPDK
was developed in the first
place.
*De:*Rob Kossler [mailto:[email protected]]
*Enviado el:* 04 November 2021 17:13
*Para:* Marcus D Leech <[email protected]>
*CC:* Guillermo Ortas Delgado <[email protected]>;
[email protected]; Anabel Almodovar <[email protected]>
*Asunto:* Re: [USRP-users] Re: UHD 4.1 error
I also recommend that you search the user's list archive regarding
DPDK. There are lots of gotchas that are not well documented (or
documented at all).
Rob
On Thu, Nov 4, 2021 at 9:43 AM Marcus D Leech
<[email protected]> wrote:
The consensus from Ettus R&D is to build the required version from
source.
Sent from my iPhone
On Nov 4, 2021, at 5:45 AM, Guillermo Ortas Delgado
<[email protected]> wrote:
Hi Marcus,
I would also like to get DPDK running and I have tried in the
past.
Let me point out a problem: the latest release of UHD requires
DPDK version 18.11, but in fact this version is not supported
on Ubuntu 20.04. The oldest available version is 19.11, so
what should I do to get it working?
I tried editing the makefile when compiling UHD to accept DPDK
version 19.11, but then the build fails mid-way. Could you
provide a solution please?
Best,
Guillermo
*De:*Marcus D. Leech [mailto:[email protected]]
*Enviado el:* 03 November 2021 16:17
*Para:* Anabel Almodovar <[email protected]>
*CC:* [email protected]
*Asunto:* [USRP-users] Re: UHD 4.1 error
On 2021-11-03 03:04, Anabel Almodovar wrote:
Thank you for your explanation. So is there any kind of
solution for my problem with GNU Radio?
Thanks in advance.
Regards,
Anabel
I have suggested this in the past--look into using DPDK if
you're running at high sample rates over 10GiGe:
https://files.ettus.com/manual/page_dpdk.html
<https://urldefense.com/v3/__https:/files.ettus.com/manual/page_dpdk.html__;!!MvyJQugb!Ug3KUJdelEBGny3uBLviYm_qf2FjZMI6Kd_bzmXKMBMc4asgXNo56mlkCx8$>
https://kb.ettus.com/Getting_Started_with_DPDK_and_UHD
<https://urldefense.com/v3/__https:/kb.ettus.com/Getting_Started_with_DPDK_and_UHD__;!!MvyJQugb!Ug3KUJdelEBGny3uBLviYm_qf2FjZMI6Kd_bzmXKMBMc4asgXNo5jyS_8IE$>
El mié, 27 oct 2021 a las 17:48, Marcus D. Leech
(<[email protected]>) escribió:
On 2021-10-27 11:37, Anabel Almodovar wrote:
Hello,
When I run a benchmark_rate example it indicates
that there are no sample losses even with 30s of
acquisition.
*/rack_2021@rack-HP-Z4-G4-Workstation:~/workarea-uhd/uhd/host/examples/build$
sudo ./benchmark_rate
--args="addr=192.168.40.2,second_addr=192.168.30.2,recv_buff_size=900000000"
--channels="0,1" --rx_rate 200e6 --duration 30
--rx_subdev="A:0 B:0"
[INFO] [UHD] linux; GNU C++ version 9.3.0;
Boost_107100; UHD_4.1.0.HEAD-0-gd21735d5
[00:00:00.000677] Creating the usrp device with:
addr=192.168.40.2,second_addr=192.168.30.2,recv_buff_size=900000000...
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 8000 bytes.
[INFO] [X300] Maximum frame size: 8000 bytes.
[INFO] [X300] Radio 1x clock: 200 MHz
Using Device: Single USRP:
Device: X-Series Device
Mboard 0: X310
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: UBX RX
RX Channel: 1
RX DSP: 1
RX Dboard: B
RX Subdev: UBX RX
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: UBX TX
TX Channel: 1
TX DSP: 1
TX Dboard: B
TX Subdev: UBX TX
[00:00:02.923799498] 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] [0/Radio#0] Attempting to set tick rate
to 0. Skipping.
[WARNING] [0/Radio#1] Attempting to set tick rate
to 0. Skipping.
[00:00:04.262875535] Testing receive rate
200.000000 Msps on 2 channels
[00:00:34.313774651] Benchmark complete.
Benchmark rate summary:
Num received samples: 12000000380
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!/*
However, when I run rx_samples_to_file I get
overflows from 8 sec for a single receiving channel.
*/sudo ./rx_samples_to_file
--file="/home/rack_2021/Escritorio/pruebas_codigos_agosto/usrp_samples.dat"
--duration 8
--args="addr=192.168.40.2,second_addr=192.168.30.2,recv_buff_size=900000000"
--channel="0" --subdev="A:0" --rate 200e6 --bw
200e6 --gain 5 --freq 800e6
Creating the usrp device with:
addr=192.168.40.2,second_addr=192.168.30.2,recv_buff_size=900000000...
[INFO] [UHD] linux; GNU C++ version 9.3.0;
Boost_107100; UHD_4.1.0.HEAD-0-gd21735d5
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 8000 bytes.
[INFO] [X300] Maximum frame size: 8000 bytes.
[INFO] [X300] Radio 1x clock: 200 MHz
Using Device: Single USRP:
Device: X-Series Device
Mboard 0: X310
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: UBX RX
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: UBX TX
TX Channel: 1
TX DSP: 1
TX Dboard: B
TX Subdev: UBX TX
Setting RX Rate: 200.000000 Msps...
Actual RX Rate: 200.000000 Msps...
Setting RX Freq: 800.000000 MHz...
Setting RX LO Offset: 0.000000 MHz...
Actual RX Freq: 800.000000 MHz...
Setting RX Gain: 5.000000 dB...
Actual RX Gain: 5.000000 dB...
Setting RX Bandwidth: 200.000000 MHz...
Actual RX Bandwidth: 200.000000 MHz...
Waiting for "lo_locked": ++++++++++ locked.
Press Ctrl + C to stop streaming...
O
Done!/*
I am using a native Ubuntu, not a VM and I have
the CPU governor set to "performance".
I have managed to patch the code that worked for
me before updating the system to the new versions
of Ubuntu and UHD, so I ask for more samples than
I want since I have observed that the recv ()
reception buffer is not always constant and it
does not always acquire the maximum number of
samples as I request (1996 samples), at least not
at the beginning. But I would like to know the
cause of this so that I can fix it and why GNU
Radio keeps giving me the same error.
Thanks in advance.
Regards,
Anabel
The recv() call doesn't necessarily guarantee that
you'll get all the samples you asked for in that call,
as far as I know. It isn't surprising that there would
be slight differences
in behavior across different versions of UHD and OS
versions in this regard. You always have to be
prepared to receive fewer samples than you asked for.
If Gnu Radio applications are producing overruns, that
is firmly in the territory of Gnu Radio, and NOT UHD.
Clearly, on your machine, UHD is able to sustain 200e6
SPS.
But as you add layers of application processing, the
system is more heavily loaded. Gnu Radio actually
"does things" with the samples, which means the
instructions-per-sample is MUCH higher than your
simple rx_samples_to_file test.
P Please consider the environment before printing this e-mail.
_______________________________________________
USRP-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
PPlease consider the environment before printing this e-mail.
_______________________________________________
USRP-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
