On 20/07/2024 14:37, cjohn...@serranosystems.com wrote:
Dear Ettus Support Team,
I hope this message finds you well. We are currently using the X310
(FPGA 39.2) with a 10GigE interface, handling 1996 samples (4 bytes
each) per packet. Despite following all recommended setup tips and
tricks for the USRP and our Linux box, we occasionally encounter “U”
(underflow) indicators. Below are additional setup notes for your
reference.
Our Questions and Requests:
1.
*FPGA Rx Buffer Size:*
*
What is the FPGA Rx buffer size on the X310?
*
I understand that this value cannot be set from the host side
and requires changes to the FPGA source. Could you confirm
this understanding?
2.
*Setting and Getting Host Parameters:*
*
We are interested in setting and getting the values of three
specific host parameters: |num_send_frames|,
|send_frame_size|, and |send_buff_size|.
*
The Ettus documentation for "Transport Notes" mentions that
values can be specified using device arguments, which
configure the transport, overriding the default values chosen
by UHD.
*
How do we properly set and verify these values? The UHD API
does not provide a direct method to retrieve these parameters,
making it unclear if they are set correctly.
They are set as *device arguments*, NOT *stream arguments*. See any of
the examples that take a --args
parameters.
https://files.ettus.com/manual/page_configuration.html
It is true that there is no API that allows you to query their state.
1.
*
For example, using |stream_args.args["foo"] = "512";| does not
indicate an error, so setting |num_send_frames| in the same
way does not guarantee that the value is applied. How can we
ensure these settings are correctly applied?
2.
*Suggestions for Mitigating Underflow ("U") Issues:*
*
Could you provide suggestions on how to adjust our
configuration or other potential fixes to eliminate the "U"
indicators?
Setup Notes:
*
*Operating System:* Ubuntu 20.04 Linux with Real Time scheduler at
a very high priority (-81).
*
*Hardware Specifications:*
o
64 cores / 4 GPUs / >250GB RAM running at 3.5 GHz.
o
Example analysis for CPU 63:
|yamlCopy codedriver: intel_cpufreq CPUs which run at the same
hardware frequency: 63 CPUs which need to have their frequency
coordinated by software: 63 maximum transition latency: 20.0
us. hardware limits: 800 MHz - 3.50 GHz available cpufreq
governors: conservative, ondemand, userspace, powersave,
performance, schedutil current policy: frequency should be
within 800 MHz and 3.50 GHz. The governor "performance" may
decide which speed to use within this range. current CPU
frequency is 3.50 GHz. |
*
*Software Settings:*
o
Based on your recommendations, we
o
See thread
https://lists.ettus.com/empathy/thread/P5LALBA6HSLEDTND4Z6IGTSZTEG3P5GX
o
“For the first version can you try setting has_time_spec to
false after the
first packet is sent, and don't bother to set the time_spec on
subsequent
packets within a burst? The time_spec should really only be
for the first
packet. The radio will ignore the timestamp on the subsequent
packets
within a burst, and I noticed we set has_time_spec to false
after the first
packet in our benchmark_rate example.”
o
https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks
, not using DPDK.
Thank you for your assistance and support. We look forward to your
guidance on these issues.
Given that you have done all the above, and the performance of your
system, the only other thing to try is DPDK, assuming
that you have a network card that can support DPDK.
_______________________________________________
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-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
