PG

peter.gu (at) tum.de

Sun, Sep 21, 2025 8:38 PM

Hello,

to try out RFNoC on my X440 under UHD 4.8 I followed this instruction:

https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0

Building the default FPGA Image via x440_X4_1600_rfnoc_image_core.yml works.

But when I try to continue with “Example: Adding an FFT Block“ it doesn’t work anymore.

1.) Although the tutorial states that “All SEPs are automatically connected to the CHDR crossbar, so this effectively connects the FFT block to the crossbar, allowing it to communicate with anything on the RFNoC network.“, I will get an error that it needs an 10x10 matrix for crossbar_routes. So I fixed this with the following matrix:

crossbar_routes:

# eth0 eth2 dma ep1 ep3

# eth1 eth3 ep0 ep2

[ 1, 0, 0, 0, 0, 1, 1, 1, 1, 1 ] # eth0 (QSFP Port 0, Lane 0)
[ 0, 1, 0, 0, 0, 1, 1, 1, 1, 1 ] # eth1 (QSFP Port 0, Lane 1)
[ 0, 0, 1, 0, 0, 1, 1, 1, 1, 1 ] # eth2 (QSFP Port 0, Lane 2)
[ 0, 0, 0, 1, 0, 1, 1, 1, 1, 1 ] # eth3 (QSFP Port 0, Lane 3)
[ 0, 0, 0, 0, 1, 1, 1, 1, 1, 1 ] # dma
[ 1, 1, 1, 1, 1, 0, 0, 1, 1, 1 ] # ep0 (radio0.0)
[ 1, 1, 1, 1, 1, 0, 0, 1, 1, 1 ] # ep1 (radio1.0)
[ 1, 1, 1, 1, 1, 1, 1, 0, 0, 0 ] # ep2 (replay0.0)
[ 1, 1, 1, 1, 1, 1, 1, 0, 0, 0 ] # ep3 (replay1.0)
[ 1, 1, 1, 1, 1, 1, 1, 0, 0, 0 ] # ep3 (fft)

The image build fails after roughly 7 hours, with the error:

CRITICAL WARNING: [Route 35-39] The design did not meet timing requirements. Please run report_timing_summary for detailed reports.

Do you know where I did a mistake in understanding the tutorial?

Thanks!

Hello, to try out RFNoC on my X440 under UHD 4.8 I followed this instruction: https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0 Building the default FPGA Image via x440_X4_1600_rfnoc_image_core.yml works. But when I try to continue with “Example: Adding an FFT Block“ it doesn’t work anymore. 1\.) Although the tutorial states that “All SEPs are automatically connected to the CHDR crossbar, so this effectively connects the FFT block to the crossbar, allowing it to communicate with anything on the RFNoC network.“, I will get an error that it needs an 10x10 matrix for crossbar_routes. So I fixed this with the following matrix: crossbar_routes: \# eth0 eth2 dma ep1 ep3 \# eth1 eth3 ep0 ep2 - \[ 1, 0, 0, 0, 0, 1, 1, 1, 1, 1 \] # eth0 (QSFP Port 0, Lane 0) - \[ 0, 1, 0, 0, 0, 1, 1, 1, 1, 1 \] # eth1 (QSFP Port 0, Lane 1) - \[ 0, 0, 1, 0, 0, 1, 1, 1, 1, 1 \] # eth2 (QSFP Port 0, Lane 2) - \[ 0, 0, 0, 1, 0, 1, 1, 1, 1, 1 \] # eth3 (QSFP Port 0, Lane 3) - \[ 0, 0, 0, 0, 1, 1, 1, 1, 1, 1 \] # dma - \[ 1, 1, 1, 1, 1, 0, 0, 1, 1, 1 \] # ep0 (radio0.0) - \[ 1, 1, 1, 1, 1, 0, 0, 1, 1, 1 \] # ep1 (radio1.0) - \[ 1, 1, 1, 1, 1, 1, 1, 0, 0, 0 \] # ep2 (replay0.0) - \[ 1, 1, 1, 1, 1, 1, 1, 0, 0, 0 \] # ep3 (replay1.0) - \[ 1, 1, 1, 1, 1, 1, 1, 0, 0, 0 \] # ep3 (fft) 2) The image build fails after roughly 7 hours, with the error: CRITICAL WARNING: \[Route 35-39\] The design did not meet timing requirements. Please run report_timing_summary for detailed reports. Do you know where I did a mistake in understanding the tutorial? Thanks!

MB

Martin Braun

Mon, Sep 22, 2025 8:02 AM

Peter,

welcome to the world of RFNoC. You did almost everything right. A couple of
notes:

The statement about SEPs being automatically corrected predates the
feature of providing a crossbar matrix. If there was no crossbar matrix,
then this would autoconnect everything.
On an FPGA, there is limited hardware to implement all the logic. The
"fuller" the design, the less likely the FPGA build tool (Vivado) will be
able to generate a valid design. That's when you get the timing error. The
x440_X4_1600 image is already pretty full, so I'm not surprised it fails.
You can still try and make it work by finding some optimizations. Here
are options:
- You can statically connect the FFT instead of dynamically. That will
  reduce the size of the crossbar and require one less stream endpoint.
- You can try and turn more 1s in the crossbar routes matrix into zeros.
  The reason we have this matrix in the first place is to exactly solve this
  problem (not enough resources on the FPGA).
- You can also try and kick off several builds and hope you get lucky
  (but only if the design is not too full).
- If necessary, you might have to remove some blocks (do you need the
  replay blocks, for example?)

I hope this gets you unstuck.

--M

On Sun, Sep 21, 2025 at 10:38 PM Peter Gu via USRP-users <
usrp-users@lists.ettus.com> wrote:

Hello,

to try out RFNoC on my X440 under UHD 4.8 I followed this instruction:

https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0

Building the default FPGA Image via x440_X4_1600_rfnoc_image_core.yml
works.

But when I try to continue with “Example: Adding an FFT Block“ it doesn’t
work anymore.

1.) Although the tutorial states that “All SEPs are automatically
connected to the CHDR crossbar, so this effectively connects the FFT block
to the crossbar, allowing it to communicate with anything on the RFNoC
network.“, I will get an error that it needs an 10x10 matrix for
crossbar_routes. So I fixed this with the following matrix:

crossbar_routes:

eth0 eth2 dma ep1 ep3

eth1 eth3 ep0 ep2

[ 1, 0, 0, 0, 0, 1, 1, 1, 1, 1 ] # eth0 (QSFP Port 0, Lane 0)
[ 0, 1, 0, 0, 0, 1, 1, 1, 1, 1 ] # eth1 (QSFP Port 0, Lane 1)
[ 0, 0, 1, 0, 0, 1, 1, 1, 1, 1 ] # eth2 (QSFP Port 0, Lane 2)
[ 0, 0, 0, 1, 0, 1, 1, 1, 1, 1 ] # eth3 (QSFP Port 0, Lane 3)
[ 0, 0, 0, 0, 1, 1, 1, 1, 1, 1 ] # dma
[ 1, 1, 1, 1, 1, 0, 0, 1, 1, 1 ] # ep0 (radio0.0)
[ 1, 1, 1, 1, 1, 0, 0, 1, 1, 1 ] # ep1 (radio1.0)
[ 1, 1, 1, 1, 1, 1, 1, 0, 0, 0 ] # ep2 (replay0.0)
[ 1, 1, 1, 1, 1, 1, 1, 0, 0, 0 ] # ep3 (replay1.0)
[ 1, 1, 1, 1, 1, 1, 1, 0, 0, 0 ] # ep3 (fft)

The image build fails after roughly 7 hours, with the error:

CRITICAL WARNING: [Route 35-39] The design did not meet timing
requirements. Please run report_timing_summary for detailed reports.

Do you know where I did a mistake in understanding the tutorial?

Thanks!

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

Peter, welcome to the world of RFNoC. You did almost everything right. A couple of notes: - The statement about SEPs being automatically corrected predates the feature of providing a crossbar matrix. If there was no crossbar matrix, then this would autoconnect everything. - On an FPGA, there is limited hardware to implement all the logic. The "fuller" the design, the less likely the FPGA build tool (Vivado) will be able to generate a valid design. That's when you get the timing error. The x440_X4_1600 image is already pretty full, so I'm not surprised it fails. - You can still try and make it work by finding some optimizations. Here are options: - You can statically connect the FFT instead of dynamically. That will reduce the size of the crossbar and require one less stream endpoint. - You can try and turn more 1s in the crossbar routes matrix into zeros. The reason we have this matrix in the first place is to exactly solve this problem (not enough resources on the FPGA). - You can also try and kick off several builds and hope you get lucky (but only if the design is not too full). - If necessary, you might have to remove some blocks (do you need the replay blocks, for example?) I hope this gets you unstuck. --M On Sun, Sep 21, 2025 at 10:38 PM Peter Gu via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello, > > to try out RFNoC on my X440 under UHD 4.8 I followed this instruction: > > https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0 > > Building the default FPGA Image via x440_X4_1600_rfnoc_image_core.yml > works. > > But when I try to continue with “Example: Adding an FFT Block“ it doesn’t > work anymore. > > 1.) Although the tutorial states that “All SEPs are automatically > connected to the CHDR crossbar, so this effectively connects the FFT block > to the crossbar, allowing it to communicate with anything on the RFNoC > network.“, I will get an error that it needs an 10x10 matrix for > crossbar_routes. So I fixed this with the following matrix: > > crossbar_routes: > > # eth0 eth2 dma ep1 ep3 > > # eth1 eth3 ep0 ep2 > > - [ 1, 0, 0, 0, 0, 1, 1, 1, 1, 1 ] # eth0 (QSFP Port 0, Lane 0) > > - [ 0, 1, 0, 0, 0, 1, 1, 1, 1, 1 ] # eth1 (QSFP Port 0, Lane 1) > > - [ 0, 0, 1, 0, 0, 1, 1, 1, 1, 1 ] # eth2 (QSFP Port 0, Lane 2) > > - [ 0, 0, 0, 1, 0, 1, 1, 1, 1, 1 ] # eth3 (QSFP Port 0, Lane 3) > > - [ 0, 0, 0, 0, 1, 1, 1, 1, 1, 1 ] # dma > > - [ 1, 1, 1, 1, 1, 0, 0, 1, 1, 1 ] # ep0 (radio0.0) > > - [ 1, 1, 1, 1, 1, 0, 0, 1, 1, 1 ] # ep1 (radio1.0) > > - [ 1, 1, 1, 1, 1, 1, 1, 0, 0, 0 ] # ep2 (replay0.0) > > - [ 1, 1, 1, 1, 1, 1, 1, 0, 0, 0 ] # ep3 (replay1.0) > > - [ 1, 1, 1, 1, 1, 1, 1, 0, 0, 0 ] # ep3 (fft) > > > 2) The image build fails after roughly 7 hours, with the error: > > CRITICAL WARNING: [Route 35-39] The design did not meet timing > requirements. Please run report_timing_summary for detailed reports. > > > Do you know where I did a mistake in understanding the tutorial? > > > Thanks! > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-leave@lists.ettus.com >

PG

peter.gu (at) tum.de

Wed, Sep 24, 2025 3:38 PM

Hello Martin,

thanks for the fast reply! I managed to build the image with three SEPs and just one replay block. However I have three more questions:

I was not able to find a .grc template which was given in <UHD4.6, e.g. shown in this video https://www.youtube.com/watch?v=M9ntwQie9vs Are there any examples available from your team?
https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0#Example_RFNoC_Image states that the rfnoc_modtool should be used. However according to https://man.archlinux.org/man/extra/libuhd/rfnoc_modtool.1.en there are way more instructions, e.g. add-gr-oot. I know this instruction is for UHD4.9.0.0, but I wasn’t able to find it for UHD4.8.0.0, which i am currently using. In UHD4.8.0.0, it seems that rfnoc_modtool only supports create and add.

Further, it seems to me that there are no instructions available how to use rfnoc_modtool, did i just missed them and if yes, can you please send me the link?

I saw that you moved from .v to .sv files. What are the reasons?

Thanks!

Best,

Peter

Hello Martin, thanks for the fast reply! I managed to build the image with three SEPs and just one replay block. However I have three more questions: 1) I was not able to find a .grc template which was given in <UHD4.6, e.g. shown in this video https://www.youtube.com/watch?v=M9ntwQie9vs Are there any examples available from your team? 2) https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0#Example_RFNoC_Image states that the rfnoc_modtool should be used. However according to https://man.archlinux.org/man/extra/libuhd/rfnoc_modtool.1.en there are way more instructions, e.g. add-gr-oot. I know this instruction is for UHD4.9.0.0, but I wasn’t able to find it for UHD4.8.0.0, which i am currently using. In UHD4.8.0.0, it seems that rfnoc_modtool only supports create and add. Further, it seems to me that there are no instructions available how to use rfnoc_modtool, did i just missed them and if yes, can you please send me the link? 3) I saw that you moved from .v to .sv files. What are the reasons? Thanks! Best, Peter

MB

Martin Braun

Wed, Sep 24, 2025 4:14 PM

Not sure on the .grc file, maybe you can provide a timestamp? But all of
our example .grc files are in current GNU Radio in the gr-uhd directory (
https://github.com/gnuradio/gnuradio/tree/main/gr-uhd/examples/grc).
We're still catching up with the docs, so I'm afraid we don't have good
docs for rfnoc_modtool outside the man page. If you want to add GNU Radio
bindings and are using UHD 4.8, then you can use a combination of
gr_modtool to generate a GNU Radio OOT within your RFNoC OOT, and perusal
of the rfnoc-gain example OOT that we provide to see what the end result
should look like.
We're slowly standardizing on SystemVerilog over Verilog, because it just
has so many good features. For that reason, new files generated from
rfnoc_modtool simply are all .sv files, even though the code didn't' change
(a bit like C/C++, Verilog is a subset of SystemVerilog so it will still
compile to the same RTL).

--M

On Wed, Sep 24, 2025 at 5:39 PM Peter Gu via USRP-users <
usrp-users@lists.ettus.com> wrote:

Hello Martin,

thanks for the fast reply! I managed to build the image with three SEPs
and just one replay block. However I have three more questions:

I was not able to find a .grc template which was given in <UHD4.6, e.g.
shown in this video https://www.youtube.com/watch?v=M9ntwQie9vs Are there
any examples available from your team?

https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0#Example_RFNoC_Image
states that the rfnoc_modtool should be used. However according to
https://man.archlinux.org/man/extra/libuhd/rfnoc_modtool.1.en there are
way more instructions, e.g. add-gr-oot. I know this instruction is for
UHD4.9.0.0, but I wasn’t able to find it for UHD4.8.0.0, which i am
currently using. In UHD4.8.0.0, it seems that rfnoc_modtool only supports
create and add.

Further, it seems to me that there are no instructions available how to
use rfnoc_modtool, did i just missed them and if yes, can you please send
me the link?

I saw that you moved from .v to .sv files. What are the reasons?

Thanks!

Best,

Peter

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

- Not sure on the .grc file, maybe you can provide a timestamp? But all of our example .grc files are in current GNU Radio in the gr-uhd directory ( https://github.com/gnuradio/gnuradio/tree/main/gr-uhd/examples/grc). - We're still catching up with the docs, so I'm afraid we don't have good docs for rfnoc_modtool outside the man page. If you want to add GNU Radio bindings and are using UHD 4.8, then you can use a combination of gr_modtool to generate a GNU Radio OOT within your RFNoC OOT, and perusal of the rfnoc-gain example OOT that we provide to see what the end result should look like. - We're slowly standardizing on SystemVerilog over Verilog, because it just has so many good features. For that reason, new files generated from rfnoc_modtool simply are all .sv files, even though the code didn't' change (a bit like C/C++, Verilog is a subset of SystemVerilog so it will still compile to the same RTL). --M On Wed, Sep 24, 2025 at 5:39 PM Peter Gu via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello Martin, > > > thanks for the fast reply! I managed to build the image with three SEPs > and just one replay block. However I have three more questions: > > 1) I was not able to find a .grc template which was given in <UHD4.6, e.g. > shown in this video https://www.youtube.com/watch?v=M9ntwQie9vs Are there > any examples available from your team? > > 2) > https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0#Example_RFNoC_Image > states that the rfnoc_modtool should be used. However according to > https://man.archlinux.org/man/extra/libuhd/rfnoc_modtool.1.en there are > way more instructions, e.g. add-gr-oot. I know this instruction is for > UHD4.9.0.0, but I wasn’t able to find it for UHD4.8.0.0, which i am > currently using. In UHD4.8.0.0, it seems that rfnoc_modtool only supports > create and add. > > Further, it seems to me that there are no instructions available how to > use rfnoc_modtool, did i just missed them and if yes, can you please send > me the link? > > 3) I saw that you moved from .v to .sv files. What are the reasons? > > Thanks! > > > Best, > > Peter > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-leave@lists.ettus.com >

PG

peter.gu (at) tum.de

Thu, Sep 25, 2025 4:21 PM

Hello Martin,

thanks again for your reply. I managed to set up a flowgraph in GRC. However, I cannot achieve the MRC=2GHz although I’ve built my own X4_1600 image. With the attached setup, I get these warnings: [WARNING] [0/Radio#0] Requesting invalid sampling rate from device: 2000 MHz. Actual rate is: 368.64 MHz.

I’ve also added the output of uhd_usrp_probe as a reference.

Is the 1600 image not supported by GR or did I just messed up smt? :D

Thanks,

Peter

Hello Martin, thanks again for your reply. I managed to set up a flowgraph in GRC. However, I cannot achieve the MRC=2GHz although I’ve built my own X4_1600 image. With the attached setup, I get these warnings: \[WARNING\] \[0/Radio#0\] Requesting invalid sampling rate from device: 2000 MHz. Actual rate is: **368.64 MHz.** I’ve also added the output of uhd_usrp_probe as a reference. Is the 1600 image not supported by GR or did I just messed up smt? :D Thanks, Peter

PG

peter.gu (at) tum.de

Fri, Sep 26, 2025 7:38 AM

I was able to set the MCR via device args in RFNoC Graph. I got it from an example…however i found nothing in the documentation about that. Am I looking into the wrong specs or is the idea to look into the c code?

Moreover, with Ch0 bandwidth also set to 1.6GHz now, I still cannot detect the cosine signal in loopback mode…did i still miss something?

Best,

Peter

I was able to set the MCR via device args in RFNoC Graph. I got it from an example…however i found nothing in the [documentation](https://wiki.gnuradio.org/index.php?title=RFNoC_Graph_(Device) "documentation") about that. Am I looking into the wrong specs or is the idea to look into the c code? Moreover, with Ch0 bandwidth also set to 1.6GHz now, I still cannot detect the cosine signal in loopback mode…did i still miss something? Best, Peter

MB

Martin Braun

Fri, Sep 26, 2025 8:45 AM

The device manual is probably the best place to start reading (
https://files.ettus.com/manual/page_usrp_x4xx.html). As for your example,
streaming 2 Gsps through GNU Radio (or any other software) is tricky. I
would expect your session to cough up a lot of errors/warnings about being
unable to keep up (like, UUUUUUUUU.... or OOOOOOOOO...).

The RF settings also don't match up. Your MCR is 2 Gsps, which will let the
converters run at 4 GHz (
https://kb.ettus.com/About_Sampling_Rates_and_Master_Clock_Rates_for_the_USRP_X440#X440_Supported_Master_Clock_Rates_.28MCR.29).
So your first Nyquist zone is < 2 GHz. But both your center frequency and
sine wave frequency are at 1 GHz, so you've moved your signal out of that
zone.

I would suggest starting with much, much lower rates until you see the
signal that you expect (start with 125 Msps). You can scale up rates as you
go. If you're in the few-hundred-megasamples range, your computer should be
able to keep up.

Best of luck,

---M

On Fri, Sep 26, 2025 at 9:39 AM Peter Gu via USRP-users <
usrp-users@lists.ettus.com> wrote:

I was able to set the MCR via device args in RFNoC Graph. I got it from an
example…however i found nothing in the documentation
https://wiki.gnuradio.org/index.php?title=RFNoC_Graph_(Device) about
that. Am I looking into the wrong specs or is the idea to look into the c
code?

Moreover, with Ch0 bandwidth also set to 1.6GHz now, I still cannot detect
the cosine signal in loopback mode…did i still miss something?

Best,

Peter

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

The device manual is probably the best place to start reading ( https://files.ettus.com/manual/page_usrp_x4xx.html). As for your example, streaming 2 Gsps through GNU Radio (or any other software) is tricky. I would expect your session to cough up a lot of errors/warnings about being unable to keep up (like, UUUUUUUUU.... or OOOOOOOOO...). The RF settings also don't match up. Your MCR is 2 Gsps, which will let the converters run at 4 GHz ( https://kb.ettus.com/About_Sampling_Rates_and_Master_Clock_Rates_for_the_USRP_X440#X440_Supported_Master_Clock_Rates_.28MCR.29). So your first Nyquist zone is < 2 GHz. But both your center frequency and sine wave frequency are at 1 GHz, so you've moved your signal out of that zone. I would suggest starting with much, much lower rates until you see the signal that you expect (start with 125 Msps). You can scale up rates as you go. If you're in the few-hundred-megasamples range, your computer should be able to keep up. Best of luck, ---M On Fri, Sep 26, 2025 at 9:39 AM Peter Gu via USRP-users < usrp-users@lists.ettus.com> wrote: > I was able to set the MCR via device args in RFNoC Graph. I got it from an > example…however i found nothing in the documentation > <https://wiki.gnuradio.org/index.php?title=RFNoC_Graph_(Device)> about > that. Am I looking into the wrong specs or is the idea to look into the c > code? > > > Moreover, with Ch0 bandwidth also set to 1.6GHz now, I still cannot detect > the cosine signal in loopback mode…did i still miss something? > > Best, > > Peter > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-leave@lists.ettus.com >

PG

peter.gu (at) tum.de

Fri, Sep 26, 2025 5:56 PM

Hi Martin,

I tried to get rid of the underflow issue but didnt succeed. Our setup consists of a host PC equipped with an AMD Threadripper Pro 3955WX (16 cores), 160 GB of RAM, and a Mellanox MT27800. It is connected to the X440 via a single 100 GbE cable.

Im using the default X440_X4_1600 image and UHD4.8.0.0

To use DPDK I followed this instruction: https://kb.ettus.com/Getting_Started_with_DPDK_and_UHD

The only thing I changed was the line dpdk_driver=/usr/lib/x86_64-linux-gnu/dpdk/pmds-20.0/ -> dpdk_driver=/usr/lib/x86_64-linux-gnu/dpdk/pmds-22.0/ in uhd.conf

I also played around with dpdk_num_mbufs by setting it to e.g. 8192.

However, I still get underflow issues:

[INFO] [UHD] linux; GNU C++ version 13.1.0; Boost_107400; DPDK_21.11; UHD_4.8.0.0-0-g308126a4

EAL: Detected CPU lcores: 32

EAL: Detected NUMA nodes: 1

EAL: Detected shared linkage of DPDK

EAL: Multi-process socket /var/run/dpdk/rte/mp_socket

EAL: Selected IOVA mode 'VA'

EAL: No available 1048576 kB hugepages reported

EAL: Probe PCI driver: mlx5_pci (15b3:1017) device: 0000:41:00.0 (socket 0)

EAL: Probe PCI driver: mlx5_pci (15b3:1017) device: 0000:41:00.1 (socket 0)

TELEMETRY: No legacy callbacks, legacy socket not created

[00:00:00.000240] Creating the usrp device with: addr=192.168.60.243,mgmt_addr=10.157.161.243,master_clock_rate=2e9,use_dpdk=1...

[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=10.157.161.243,type=x4xx,product=x440,serial=32C7660,name=ni-x4xx-32C7660,fpga=X4_1600,claimed=False,addr=192.168.60.243,master_clock_rate=2e9,use_dpdk=1

[WARNING] [MPM.RPCServer] A timeout event occured!

[INFO] [MPM.PeriphManager] init() called with device args `fpga=X4_1600,master_clock_rate=(2000000000.0, 2000000000.0),mgmt_addr=10.157.161.243,name=ni-x4xx-32C7660,product=x440,use_dpdk=1,clock_source=internal,time_source=internal,initializing=True'.

Using Device: Single USRP:

Device: X400-Series Device

Mboard 0: x440

RX Channel: 0

RX DSP: n/a

RX Dboard: A

RX Subdev: 0

TX Channel: 0

TX DSP: n/a

TX Dboard: A

TX Subdev: 0

[00:00:03.670625969] Setting device timestamp to 0...

[00:00:03.673117806] Testing receive rate 2000.000000 Msps on 1 channels

Setting TX samples per packet (spp) to 1984

Setting TX samples per burst (spb) to 1984

[00:00:03.675296572] Testing transmit rate 2000.000000 Msps on 1 channels

OUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUterminate called after throwing an instance of 'uhd::op_timeout'

what(): RfnocError: OpTimeout: Control operation timed out waiting for ACK

Aborted (core dumped)

What can be the issue here?

Best,

Peter

Hi Martin, I tried to get rid of the underflow issue but didnt succeed. Our setup consists of a host PC equipped with an AMD Threadripper Pro 3955WX (16 cores), 160 GB of RAM, and a Mellanox MT27800. It is connected to the X440 via a single 100 GbE cable. Im using the default X440_X4_1600 image and UHD4.8.0.0 To use DPDK I followed this instruction: https://kb.ettus.com/Getting_Started_with_DPDK_and_UHD The only thing I changed was the line dpdk_driver=/usr/lib/x86_64-linux-gnu/dpdk/pmds-20.0/ -> dpdk_driver=/usr/lib/x86_64-linux-gnu/dpdk/pmds-22.0/ in uhd.conf I also played around with dpdk_num_mbufs by setting it to e.g. 8192. However, I still get underflow issues: \[INFO\] \[UHD\] linux; GNU C++ version 13.1.0; Boost_107400; DPDK_21.11; UHD_4.8.0.0-0-g308126a4 EAL: Detected CPU lcores: 32 EAL: Detected NUMA nodes: 1 EAL: Detected shared linkage of DPDK EAL: Multi-process socket /var/run/dpdk/rte/mp_socket EAL: Selected IOVA mode 'VA' EAL: No available 1048576 kB hugepages reported EAL: Probe PCI driver: mlx5_pci (15b3:1017) device: 0000:41:00.0 (socket 0) EAL: Probe PCI driver: mlx5_pci (15b3:1017) device: 0000:41:00.1 (socket 0) TELEMETRY: No legacy callbacks, legacy socket not created \[00:00:00.000240\] Creating the usrp device with: addr=192.168.60.243,mgmt_addr=10.157.161.243,master_clock_rate=2e9,use_dpdk=1... \[INFO\] \[MPMD\] Initializing 1 device(s) in parallel with args: mgmt_addr=10.157.161.243,type=x4xx,product=x440,serial=32C7660,name=ni-x4xx-32C7660,fpga=X4_1600,claimed=False,addr=192.168.60.243,master_clock_rate=2e9,use_dpdk=1 \[WARNING\] \[MPM.RPCServer\] A timeout event occured! \[INFO\] \[MPM.PeriphManager\] init() called with device args \`fpga=X4_1600,master_clock_rate=(2000000000.0, 2000000000.0),mgmt_addr=10.157.161.243,name=ni-x4xx-32C7660,product=x440,use_dpdk=1,clock_source=internal,time_source=internal,initializing=True'. Using Device: Single USRP: Device: X400-Series Device Mboard 0: x440 RX Channel: 0 RX DSP: n/a RX Dboard: A RX Subdev: 0 TX Channel: 0 TX DSP: n/a TX Dboard: A TX Subdev: 0 \[00:00:03.670625969\] Setting device timestamp to 0... \[00:00:03.673117806\] Testing receive rate 2000.000000 Msps on 1 channels Setting TX samples per packet (spp) to 1984 Setting TX samples per burst (spb) to 1984 \[00:00:03.675296572\] Testing transmit rate 2000.000000 Msps on 1 channels OUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUterminate called after throwing an instance of 'uhd::op_timeout' what(): RfnocError: OpTimeout: Control operation timed out waiting for ACK Aborted (core dumped) What can be the issue here? Best, Peter

MM

Marcus Müller

Tue, Sep 30, 2025 2:07 PM

Hi Peter,

as Martin said, unlikely ("no way") you'll be processing 2 GS/s in computer software, DPDK
or not. Start smaller; channelize / process-on-FPGA as needed.

Best,
Marcus

On 9/26/25 7:56 PM, Peter Gu via USRP-users wrote:

Hi Martin,

I tried to get rid of the underflow issue but didnt succeed. Our setup consists of a
host PC equipped with an AMD Threadripper Pro 3955WX (16 cores), 160 GB of RAM, and a
Mellanox MT27800. It is connected to the X440 via a single 100 GbE cable.

Im using the default X440_X4_1600 image and UHD4.8.0.0

To use DPDK I followed this instruction:
https://kb.ettus.com/Getting_Started_with_DPDK_and_UHD

The only thing I changed was the line
dpdk_driver=/usr/lib/x86_64-linux-gnu/dpdk/pmds-20.0/ ->
dpdk_driver=/usr/lib/x86_64-linux-gnu/dpdk/pmds-22.0/ in uhd.conf

I also played around with dpdk_num_mbufs by setting it to e.g. 8192.

However, I still get underflow issues:

[INFO] [UHD] linux; GNU C++ version 13.1.0; Boost_107400; DPDK_21.11;
UHD_4.8.0.0-0-g308126a4

EAL: Detected CPU lcores: 32

EAL: Detected NUMA nodes: 1

EAL: Detected shared linkage of DPDK

EAL: Multi-process socket /var/run/dpdk/rte/mp_socket

EAL: Selected IOVA mode 'VA'

EAL: No available 1048576 kB hugepages reported

EAL: Probe PCI driver: mlx5_pci (15b3:1017) device: 0000:41:00.0 (socket 0)

EAL: Probe PCI driver: mlx5_pci (15b3:1017) device: 0000:41:00.1 (socket 0)

TELEMETRY: No legacy callbacks, legacy socket not created

[00:00:00.000240] Creating the usrp device with:
addr=192.168.60.243,mgmt_addr=10.157.161.243,master_clock_rate=2e9,use_dpdk=1...

[INFO] [MPMD] Initializing 1 device(s) in parallel with args:
mgmt_addr=10.157.161.243,type=x4xx,product=x440,serial=32C7660,name=ni-x4xx-32C7660,fpga=X4_1600,claimed=False,addr=192.168.60.243,master_clock_rate=2e9,use_dpdk=1

[WARNING] [MPM.RPCServer] A timeout event occured!

[INFO] [MPM.PeriphManager] init() called with device args
`fpga=X4_1600,master_clock_rate=(2000000000.0,
2000000000.0),mgmt_addr=10.157.161.243,name=ni-x4xx-32C7660,product=x440,use_dpdk=1,clock_source=internal,time_source=internal,initializing=True'.

Using Device: Single USRP:

Device: X400-Series Device

Mboard 0: x440

RX Channel: 0

RX DSP: n/a

RX Dboard: A

RX Subdev: 0

TX Channel: 0

TX DSP: n/a

TX Dboard: A

TX Subdev: 0

[00:00:03.670625969] Setting device timestamp to 0...

[00:00:03.673117806] Testing receive rate 2000.000000 Msps on 1 channels

Setting TX samples per packet (spp) to 1984

Setting TX samples per burst (spb) to 1984

[00:00:03.675296572] Testing transmit rate 2000.000000 Msps on 1 channels

OUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUterminate
called after throwing an instance of 'uhd::op_timeout'

what(): RfnocError: OpTimeout: Control operation timed out waiting for ACK

Aborted (core dumped)

What can be the issue here?

Best,

Peter

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

Hi Peter, as Martin said, unlikely ("no way") you'll be processing 2 GS/s in computer software, DPDK or not. Start smaller; channelize / process-on-FPGA as needed. Best, Marcus On 9/26/25 7:56 PM, Peter Gu via USRP-users wrote: > > Hi Martin, > > I tried to get rid of the underflow issue but didnt succeed. Our setup consists of a > host PC equipped with an AMD Threadripper Pro 3955WX (16 cores), 160 GB of RAM, and a > Mellanox MT27800. It is connected to the X440 via a single 100 GbE cable. > > Im using the default X440_X4_1600 image and UHD4.8.0.0 > > To use DPDK I followed this instruction: > https://kb.ettus.com/Getting_Started_with_DPDK_and_UHD > > The only thing I changed was the line > dpdk_driver=/usr/lib/x86_64-linux-gnu/dpdk/pmds-20.0/ -> > dpdk_driver=/usr/lib/x86_64-linux-gnu/dpdk/pmds-22.0/ in uhd.conf > > I also played around with dpdk_num_mbufs by setting it to e.g. 8192. > > > However, I still get underflow issues: > > [INFO] [UHD] linux; GNU C++ version 13.1.0; Boost_107400; DPDK_21.11; > UHD_4.8.0.0-0-g308126a4 > > EAL: Detected CPU lcores: 32 > > EAL: Detected NUMA nodes: 1 > > EAL: Detected shared linkage of DPDK > > EAL: Multi-process socket /var/run/dpdk/rte/mp_socket > > EAL: Selected IOVA mode 'VA' > > EAL: No available 1048576 kB hugepages reported > > EAL: Probe PCI driver: mlx5_pci (15b3:1017) device: 0000:41:00.0 (socket 0) > > EAL: Probe PCI driver: mlx5_pci (15b3:1017) device: 0000:41:00.1 (socket 0) > > TELEMETRY: No legacy callbacks, legacy socket not created > > [00:00:00.000240] Creating the usrp device with: > addr=192.168.60.243,mgmt_addr=10.157.161.243,master_clock_rate=2e9,use_dpdk=1... > > [INFO] [MPMD] Initializing 1 device(s) in parallel with args: > mgmt_addr=10.157.161.243,type=x4xx,product=x440,serial=32C7660,name=ni-x4xx-32C7660,fpga=X4_1600,claimed=False,addr=192.168.60.243,master_clock_rate=2e9,use_dpdk=1 > > [WARNING] [MPM.RPCServer] A timeout event occured! > > [INFO] [MPM.PeriphManager] init() called with device args > `fpga=X4_1600,master_clock_rate=(2000000000.0, > 2000000000.0),mgmt_addr=10.157.161.243,name=ni-x4xx-32C7660,product=x440,use_dpdk=1,clock_source=internal,time_source=internal,initializing=True'. > > Using Device: Single USRP: > > Device: X400-Series Device > > Mboard 0: x440 > > RX Channel: 0 > > RX DSP: n/a > > RX Dboard: A > > RX Subdev: 0 > > TX Channel: 0 > > TX DSP: n/a > > TX Dboard: A > > TX Subdev: 0 > > [00:00:03.670625969] Setting device timestamp to 0... > > [00:00:03.673117806] Testing receive rate 2000.000000 Msps on 1 channels > > Setting TX samples per packet (spp) to 1984 > > Setting TX samples per burst (spb) to 1984 > > [00:00:03.675296572] Testing transmit rate 2000.000000 Msps on 1 channels > > OUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUterminate > called after throwing an instance of 'uhd::op_timeout' > > what(): RfnocError: OpTimeout: Control operation timed out waiting for ACK > > Aborted (core dumped) > > > What can be the issue here? > > > Best, > > Peter > > > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-leave@lists.ettus.com

usrp-users@lists.ettus.com

Getting Started RFNoC

eth0 eth2 dma ep1 ep3

eth1 eth3 ep0 ep2