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.
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. 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. 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<mailto: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<mailto: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<mailto:usrp-users@lists.ettus.com> To unsubscribe send an email to usrp-users-le...@lists.ettus.com<mailto:usrp-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
