Hi Anna,
On 28.09.23 23:49, Anna Lamkin Broome wrote:
Hi Marcus,
After a bit more testing, I am increasingly convinced that the application begins to
hang only after encountering a late command error for the first time. If this is indeed
the case, the time it takes from start of application to hanging depends on the number
of samples transmitted/received and the PRF. Basically it happens faster (on the order
of 1s to low 10s of seconds) at higher duty cycles and may not happen at all at lower
duty cycles. The tests I am currently doing attempt collect 100,000 pulses worth of data
and should finish in about 50 seconds given the specified PRF. If I slow the PRF down,
the late command errors don’t happen and the application never hangs.
Yeah, that seems to be a relatively solid indication.
Thanks for the information about the warnings being added in UHD 4.0—that certainly
explains why I wasn’t seeing them before. When you say that "in UHD 4 RFNoC is much more
tightly integrated with the host-side UHD” what do you mean by that? Forgive me if this
is an overly broad question, I’m not all that familiar with FPGA architecture.
Always appreciated here to ask such questions! So, I'm myself not too familiar with the
UHD4/RFNoC4 internals myself. But: whereas RFNoC started out as "added functionality" on
UHD 3, where it just "something between the radio controller and the streamers going to
the host PC", UHD 4 is pretty consequent in that the FPGA image is made of RFNoC
components. Cleaner, but also means that the host has more insight into what happens.
I can get exact numbers next week (no longer in lab today), but I think I was able to
run the benchmark_rate example in UHD 3.15 in full duplex at around 10-20 MHz sample
rates with no major problems (over 1GbE), whereas in UHD 4.15 a 20 MHz sample rate
causes the control op error within the first couple of seconds.
Ah, so, rather low rates, and no 10 GbE!
Gotta think about that.
Best,
Marcus
Hi Rob—Yes, I totally agree that the Replay block is probably very useful to us and may
ultimately be the way we end up going. I don’t think it was available in the standard
release FPGA image until UHD 4.1 or 4.2 and my thought was to get our existing code
working with the newer UHD prior to going down that path. Part of the upside of our
application is that it can be run on multiple SDRs in the Ettus family. So the other
reason we haven’t gone full steam into the Replay block is a desire to see if we could
get the job done well enough with our non-RFNoC application and maintain the exact same
code minus a configuration file for running on the X310 and B205mini.
Thanks for pointing out the potential difference in FIFO lengths between the UHD
releases. I’ll look into that more.
Best,
Anna
On Sep 28, 2023, at 12:31 PM, Rob Kossler <rkoss...@nd.edu> wrote:
One more thing. One difference between 3.15 and 4.xx might be the length of FIFOs on
the FPGA for buffering Tx data arriving from the host. If the 4.xx buffers are
smaller, then it may be more likely for a "glitch" to occur if your host is a bit
"bursty" when providing the samples. If this is true, then perhaps you could build a
custom X310 image with larger buffers.
On Thu, Sep 28, 2023 at 3:26 PM Rob Kossler <rkoss...@nd.edu> wrote:
Hi Anna,
I do not have a response to your direct question regarding performance.
However, I
have a suggestion that may make the performance irrelevant. The X310
image comes
with a Replay block that accesses the DRAM chip for storage. Given that you
are
sending a repeatable waveform, you should have plenty of room to store this
ahead
of time and playout from the Replay block. This is exactly how I do all of
my radar
testing. While it will take some effort to make your application play nice
with the
Replay block, it will be worth it because you will never fight "Late" or
"Underrun"
again. (Note that there may be a RAM I/O bottleneck if trying to play both
channels simultaneously from the Replay block at 200 MS/s, but one channel
will be
no problem).
Rob
On Thu, Sep 28, 2023 at 1:55 PM Anna Lamkin Broome <abro...@stanford.edu>
wrote:
Hello,
We are developing a radar application built on the Ettus SDR platforms.
Our
code runs well on an X310 with UBX160 daughterboards using UHD 3.15 and
a
B205mini-i using UHD 4.1 and another B205mini-i using UHD 4.4. We want
to take
advantage of recent power calibration utilities and other features not
present
in UHD 3.15, so I am now trying to run our code on an X310 with the
most recent
UHD 4.5 release.
When running our code on the X310 with UHD 4.5 I get warnings for both
radio 0
and radio 1 (we transmit on one UBX160 and receive on the other):
*[WARNING]
[0/Radio#0] *Attempting to set tick rate to 0. Skipping. The code uses
timed
commands to transmit and receive samples from a frequency-swept pulse
at a
consistent interval (pulse repetition frequency). Our application
requires a
high PRF and we can tolerate some late command errors, but need to log
them for
post-processing. Using UHD 4.5, the behavior is not as expected in that
something seems to be hanging. At some point during the process—I think
once we
first hit a late command error—the timing becomes very off from what it
should
be, and eventually, samples stop being transmitted or received and the
application just hangs. Sometimes when killing the application, I get
this
warning: *[WARNING] [RFNOC::GRAPH::DETAIL] *Cannot forward action
tx_event from
0/Radio#0:INPUT_EDGE:0, no neighbour found! These warnings do not
happen when
running the application with UHD 3.15.
I have tried running the benchmark_rate example with the same host
computer and
X310 running UHD 3.15 and UHD 4.5. With UHD 4.5 and high sample rates,
I get an
error: uhd::op_timeout: RfnocError: OpTimeout: Control operation timed
out
waiting for ACK, which stops the test before it begins running. Lower
sample
rates in UHD 4.5 run, but produce more errors (including sequence
errors) than
the same set up running UHD 3.15.
I have tried refreshing the FPGA image for UHD 4.5 with no change in
behavior.
The behavior is replicable using multiple host computers (Mac and
Ubuntu). If
anyone has suggestions on debugging steps, or potential reasons why UHD
4.5
would seem laggy compared to UHD 3.15 (despite running well with UHD
4.x on the
B205mini), I would greatly appreciate them. I suspect it may have
something to
do with the command queue and how it evolves after getting behind.
Thanks,
Anna Broome
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
_______________________________________________
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
