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 <patchvonbr...@gmail.com> 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 <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://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 (<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 >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
