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 <g.or...@gmv.com> 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:patchvonbr...@gmail.com] > Enviado el: 03 November 2021 16:17 > Para: Anabel Almodovar <anabel.almodo...@gmail.com> > CC: usrp-users@lists.ettus.com > 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://kb.ettus.com/Getting_Started_with_DPDK_and_UHD > > > > > El mié, 27 oct 2021 a las 17:48, Marcus D. Leech (<patchvonbr...@gmail.com>) > 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 -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
