Hi,
My goal is to transmit a stored signal at pulse repetition frequencies (PRF) in
the multi-kHz range with the x440. I'm working with a modified CG_1600 FPGA
(using 100 Gbit Ethernet and 1600 MHz bandwidth) where I incorporated the
Replay Block.
From my tests, the Replay Block itself works as expected. I’ve used the
rfnoc_replay_samples_from_file example to verify both continuous streaming and
finite sample replay, confirming the output of the radio with a spectrum
analyzer. I’m able to output the desired signal at 2Gsps, with the 40000
samples that I put in the replay block (for now it’s a fix value). But I want
to have a duty cycle of 0.1 without zero padding the rest of my signal.
However, due to the limited depth of the Replay Block's command queue, I must
issue a stream timed command for each pulse and at least at the desired PRF. If
the queue is full, attempting to issue a new command results in an error. To
avoid using try/catch for this, I’ve added a function that peeks at
REG_PLAY_CMD_FIFO_SPACE_ADDR and sends the next pulse only if space is
available. This loop runs in its own thread.
Despite all of this, I'm seeing many 'L' characters printed pointing out that
incoming stream commands are considered late by the Replay Block.
Based on my experience with UHD and Ettus hardware, I suspect the bottleneck
could lie in one of the following areas:
* The host cannot issue commands quickly enough
* The transport layer is unable to sustain the required command rate
(NIC/sockets…)
* The Replay Block cannot ingest commands at the desired speed
I analysed execution times in the loop and issue_stream_command() function.
They appeared fast enough for my application (tens of microseconds). However,
the command queue remains nearly empty. Even after optimizing the issuing logic
by eliminating unnecessary operations and reducing loop time by half, the max
issuing commands the system can generate/consume remains the same (around 1250
commands per seconds).
This leads me to believe the transport layer may be the limiting factor. One
suspicion is that if TCP is used for command transmission, the Nagle algorithm
might be delaying packets by attempting to concatenate them. If that’s the
case, is there a way to explicitly disable it (e.g. using TCP_NODELAY)? Could
you maybe briefly explain how the transport layer works for RFNoC blocks?
Alternatively, the issue could come from an entirely different source, and I
would appreciate any insights or recommendations on how to proceed.
Here are some code snippets/contexts:
In the replay_block_control :
uint64_t get_fifo_fullness(const size_t port){
return _replay_reg_iface.peek32(REG_PLAY_CMD_FIFO_SPACE_ADDR, port); }
My loop (might have some issues due to copy/pasting ; added variables for
better context):
// Set up the static part of the stream command
uhd::stream_cmd_t stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
stream_cmd.num_samps = 40000; //Is a fix value for now
stream_cmd.stream_now = false;
const double prf = 10000; //1000 works but 1500 doesn’t
const auto prf_interval_us = static_cast<int>(1e6 / prf);
const double prf_interval = 1.0 / prf;
// Loop through each "second" of pulses
for (size_t second = 0; second < number_pulses / prf; ++second) {
LOG_F(INFO, "Sending commands for second %lu", second);
// Loop through pulses within this second
for (size_t pulse = 0; pulse < prf; ++pulse) {
// Calculate the scheduled time for this pulse
stream_cmd.time_spec = uhd::time_spec_t(start_time + second + pulse *
prf_interval);
// Query the FIFO space before sending
uint32_t fullness = m_streamer.block->get_fifo_fullness(0);
if (fullness != 0) {
// FIFO has space — issue the command
m_streamer.block->issue_stream_cmd(stream_cmd, m_streamer.channel);
++n_total_pulses;
} else {
// FIFO is full — back off briefly and retry this pulse
std::this_thread::sleep_for(std::chrono::microseconds(prf_interval_us));
--pulse; // Retry current pulse
}
// Exit early if total pulse count reached
if (n_total_pulses >= number_pulses) {
break;
}
}
}
LOG_F(INFO, "Finished sending pulses!");
Software infos :
UHD 4.8.0 commit 308126a479ca19dfaebfe4784b375e608788d763
Ubuntu 22.04 jammy
Hardware infos :
CPU Intel(R) Xeon(R) Gold 5317 CPU @ 3.00GHz
For Data Plane : Ethernet controller: Intel Corporation Ethernet Controller
E810-C (not used for this part)
For Command : TP-LINK Adaptateur Ethernet Gigabit USB 3.0 (UE306) -> Cannot
control the coalescing settings, maybe there is something also here?
Thanks a lot for your help!
Best regards,
Arthur
Arthur Gerst
Intern
| arthur.ge...@aerospacelab.com
[cid:240315_aerospacelab_mailbanner_brand_bd3dd1c7-bc8a-46fa-ab29-0da2ce397538.png]
Rue André Dumont 14B | 1435 Mont-Saint-Guibert | Belgium
www.aerospacelab.com<http://www.aerospacelab.com/>
The content of this email is confidential and intended for the recipient
specified in message only. It is strictly forbidden to share any part of this
message with any third party, without a written consent of the sender. If you
received this message by mistake, please reply to this message and follow with
its deletion, so that we can ensure such a mistake does not occur in the future.
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
