There are a number of emails/posts that may be of interest. Here is the one within a long chain. You can search the subject line. https://www.mail-archive.com/usrp-users@lists.ettus.com/msg11842.html
On Thu, Nov 4, 2021 at 1:56 PM Marcus D. Leech <patchvonbr...@gmail.com> wrote: > 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:rkoss...@nd.edu <rkoss...@nd.edu>] > *Enviado el:* 04 November 2021 17:13 > *Para:* Marcus D Leech <patchvonbr...@gmail.com> <patchvonbr...@gmail.com> > *CC:* Guillermo Ortas Delgado <g.or...@gmv.com> <g.or...@gmv.com>; > usrp-users@lists.ettus.com; Anabel Almodovar <anabel.almodo...@gmail.com> > <anabel.almodo...@gmail.com> > *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 <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 > > > 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
