Hi,
I have tried locking threads to cores and isolating but no luck. I don't buy
your theory because each X440 channel (endpoint) has more on-fabric buffering
than an N320. We have no problem running TX at 40 Msps on an N320.
Looking at the RFNoC YAML config:
------- N320: n320_rfnoc_image_core.yml
stream_endpoints:
ep0: # Stream endpoint name
ctrl: True # Endpoint passes control traffic
data: True # Endpoint passes data traffic
buff_size: 65536 # Ingress buffer size for data
--------
------ X440: x440_X4_200_rfnoc_image_core.yml
ep0: # Stream endpoint name
ctrl: True # Endpoint passes control traffic
data: True # Endpoint passes data traffic
buff_size_bytes: 262144 # Ingress buffer size for data
--------
If NI/Ettus is making the X4_200 image available, they must have tested.
Eugene.
________________________________
From: Chris Rogers <[email protected]>
Sent: Monday, June 29, 2026 1:41 PM
To: Eugene Grayver <[email protected]>
Cc: Peter Jiacheng Gu <[email protected]>; usrp-users <[email protected]>
Subject: Re: [USRP-users] Re: Underflows on X440 TX
A few comments here:
I have almost the exact same setup. After extensively debugging dropped samples
on Tx, I concluded that there just wasn't very much on-fabric buffering on the
X4_200 image, meaning it's very sensitive to host latency jitter which was
causing the sample drops. Using DPDK, isolating some CPUs (isolcpus), and
putting all DPDK fast-path sender threads on the isolated cores completely
solved my problems.
I would check your network interfaces and make sure the packets are going where
they should be. You can "watch -n 0.5 ifconfig" or something like that on your
host machine while you run your tests and watch the Tx/Rx packet counters tick
up. Make sure when the test starts, the management interface does some small
amount of communication and when the test is running the 100G ports do the high
speed comms.
Also, it would be awesome to get a prebuilt image with RAM buffering and
DUC/DDC enabled. I assume some resource limitation prevented an image like this
from already shipping with UHD?
On Mon, Jun 29, 2026 at 4:18 PM Eugene Grayver
<[email protected]<mailto:[email protected]>> wrote:
I have not tried the X4_400 image because I need many channels at relatively
low (50 MHz) bandwidth. This issue must be solved — I've been able to use
older USRPs for TX at rates up to 200 Msps. There is no reason for the X440 to
behave this way.
________________________________
From: Peter Jiacheng Gu <[email protected]<mailto:[email protected]>>
Sent: Monday, June 29, 2026 12:23 PM
To: Eugene Grayver <[email protected]<mailto:[email protected]>>
Cc: usrp-users <[email protected]<mailto:[email protected]>>
Subject: [EXTERNAL] Re: [USRP-users] Underflows on X440 TX
Do not open links or attachments unless you recognize the sender. If unsure,
click the Report Phish button or forward the email to OPSEC.
Hi Eugene,
I also encountered this issue. I’m currently investigating the X4_400 image
since it supports the replay block. Have you already tried this?
Best,
Peter
Am 29.06.2026 um 21:02 schrieb Eugene Grayver
<[email protected]<mailto:[email protected]>>:
Hello,
I am returning to the problem reported a few months ago:
I have two X440s with X_200 image connected to a Threadripper 24 core. I am
using two 10 GbE direct connect cables for each USRP (total of 4x 10 GbE).
I was able to get RX working, but TX is getting continuous underflows.
*
Using the benchark_rate example.
*
Underflows observed both w/ DPDK and w/out DPDK
*
Underflows observed with 4, 8 channels and 16 channels
*
Fewer underflows with 4 channels, but still get a few per minute
*
Priority high/normal does not make a difference (usually)
IMPORTANT: If I use only one interface (
—args=addr=192.168.10.2,mgmt_addr=192.168.1.10) there are no underflows with up
to 7 channels (max to fit in 10 GbE).
./benchmark_rate
--args=addr0=192.168.10.2,second_addr0=192.168.11.2,mgmt_addr0=192.168.1.10,addr1=192.168.15.2,second_addr1=192.168.16.2,mgmt_addr1=192.168.1.20,clock_source=external,use_dpdk=1,type=x4xx,product=x440
--tx_channels 0,1,2,3,4,5,6,7 --tx_rate 40.96e6 --tx_cpu sc16 --multi_streamer
--duration 120
This should be trivial for such a powerful machine!
I am suspecting an issue with handling of packets across multiple network
interfaces. Are the TX flow control packets not getting to the right place?
This is a critical failure — not something I expect for a $35k box 🙂
Eugene Grayver, Ph.D.
Principal Engineer
310-336-1274
_______________________________________________
USRP-users mailing list --
[email protected]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[email protected]>
_______________________________________________
USRP-users mailing list --
[email protected]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[email protected]>
_______________________________________________
USRP-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
